OMITted параметры можно отследить

Гость

Добрый день.

C55 ABC
С удивлением и досадой (на то, что приходилось править шаблоны, вписывая точку вставки непосредственно после CODE перед WindowManager.Run()) узнал из ньюсгрупп, что переданные в процедуру OMIT- параметры можно проверить в любой ROUTINE, вызвав её, например, в WindowManager.Init(), так как ROUTINE попадает в область видимости самой процедуры. То есть код

Код: Выделить всё

WindowManager.Init    PROCEDURE()
    CODE
    DO CheckOmittedPars
...
CheckOmittedPars    ROUTINE
    IF OMITTED(1)
...

проверит на опущенность не параметры метода Init, а параметры процедуры (той, которая видна в дереве процедур).
Помнится, было обсуждение этой темы, и если склероз не изменяет, сошлись на том, что легально это невозможно.

С уважением, ДП
Написал: ClaList(2)

Гость

Вообще-то, ничего удивительного здесь нет:
- метод Init является методом ЛОКАЛЬНОГО класса (для основной процедуры), т.е. в рамках основной процедуры все методы этого локального класса практически идентичны локальным рутинкам
- у рутинки НЕ МОЖЕТ быть подчиненной другой рутинки таким образом, все рутинки, как-бы "прицепленные" к методам локального класса, на самом деле являются ПОЛНОЦЕННЫМИ рутинками основной процедуры, со всеми, вытекающими из этого, последствиями!
Поэтому, когда компилятор встречает в такой рутинке директиву OMITTED(), то он, естественно, воспринимает ее применительно к параметрам процедуры, которая является владельцем текущей рутинки.

=============================
С уважением, Олег А. Руденко.
Oleg_Rudenko@mail.ru
Oleg_Rudenko@mail333.com
Библиотека DynaLib
http://dynalib.narod.ru
Написал: ClaList(2)

Гость

Код: Выделить всё
CheckOmittedPars    ROUTINE
     IF OMITTED(1)

А не надо досадовать, проверять OMITTED параметров процедуры в рутине метода, это очевидный изврат.

Вообще-то, ничего удивительного здесь нет:

С точки зрения имеющейся реализации, наверное. Но вот с точки зрения банальной логики, имхо это весьма удивительно. На самом деле это все означает, что нельзя проверить опущенные параметры метода в рутине, расположенной в этом методе. Что, на самом деле, является серьезными граблями. Более того, что-то мне подсказывает, что накопали сей факт именно получив по лбу этими граблями. Какой-то программист, видимо, долго не мог понять, почему у него неадекватно работает OMITTED в рутине метода.

- метод Init является методом ЛОКАЛЬНОГО класса (для основной процедуры), т.е. в рамках основной процедуры все методы этого локального класса практически идентичны локальным рутинкам

Опять же только с точки зрения имеющейся реализации. В чем практическая идентичность? Только лишь в том, что метод локального класса и локальная рутина имеют одинаковый доступ к локальным данным процедуры.

- таким образом, все рутинки, как-бы "прицепленные" к методам локального класса, на самом деле являются ПОЛНОЦЕННЫМИ рутинками основной процедуры, со всеми, вытекающими из этого, последствиями!

Ловко ты приравнял метод локального класса к локальной рутине

А как быть с тем, что рутина метода локального класса имеет доступ к локальным данным этого метода? Простым рутинам не дозволяется иметь доступ к данным друг друга, значит некая вложенность (или эмуляция таковой) все же присутствует? Дык почему бы в рамках этой вложенности не обрабатывать OMITTED параметров своего родного метода, а не процедуры?

Поэтому, когда компилятор встречает в такой рутинке директиву OMITTED(), то он, естественно, воспринимает ее применительно к параметрам процедуры, которая является владельцем текущей рутинки.

Что является, имхо, проектной ошибкой компилятора.

Удачи!
__________________________________
Владимир Якимченко (IСQ 16 993 194)
Написал: ClaList(2)

Гость

Привет, Всем!

Судя по тому, что описание рутины CheckOmittedPars расположено ниже метода ее вызывающего, я предполагаю, что данная рутина описанна в методе WindowManager.Init

Тогда возникает два вопроса.
1. А собственно чем такой вариает проще, в плане шаблонной непроходимости ABC? Насколько я понимаю, описать рутину в методе так же непросто, как и получить точку вставки сразу после CODE процедуры.

2. Почему бы не использовать для этих целей рутину "прицепленную" непосредственно к процедуре, такие рутины и описать проще, и методы локальных классов могут вызывать рутины процедуры. Вот это я понимаю, было бы логично. А так, получается мы просто приспосабливаем для своих нужд ошибку компилятора.

Удачи!
__________________________________
Владимир Якимченко
Написал: ClaList(2)

Гость

ИМХО, использовать omitable параметры в методе это дурной тон. Есть оверлоудинг. Никаких вопросов не будет. А с остальными возражениями согласен.

WBR, Nick Tsigouro mailto:nick@arsis.ru
Написал: ClaList(2)

Гость

Ну использовать или нет, это уже вопросы стиля программирования. Я использую, достаточно широко. А оверлоадинг, это несколько из другой оперы (и вопросов как раз будет масса

).

Если метод использует на входе некий параметр и допустимо для него значение по умолчанию. То почему в этом случае не использовать опускаемые параметры?

Удачи!
__________________________________
Владимир Якимченко
Написал: ClaList(2)

Гость

Можно использовать. Но в опускаемых параметрах нет ничего хитрого. Это всего лишь небольшой сервис компилятора, который оплачивается лишним параметром. А какие вопросы с оверлоудингом? особенно если опускаемых параметров 1 или 2?

Код: Выделить всё

MyClass.Metod   Procrdure()
loc:Par                 ...(DefaultParValue)
  Code
! или, если дефолтное значение не константа, а требует вычислений (напр.
хэндл текущего окна):
!  Par = ... ! Такое через опускаемый параметр вообще не сделаешь.
  Self.Metod(loc:Par)

MyClass.Metod   Procrdure(Par)
...

Я бы сказал, что опускаемые вообще лишние (legacy), но среда - дура, не дает нормально оверлоудить процедуры проекта.

WBR, Nick Tsigouro
Написал: ClaList(2)

Гость

Код: Выделить всё

MyClass.Metod Procrdure()
loc:Par ...(DefaultParValue)
  Code
! или, если дефолтное значение не константа, а требует вычислений (напр.
хэндл текущего окна):
!  Par = ... ! Такое через опускаемый параметр вообще не сделаешь.

Ну да?! Пример в студию!

Сергей - chusha@mail333.com ; chusha@hotbox.ru
Написал: ClaList(2)

Гость

Пример чего?

WBR, Nick Tsigouro
Написал: ClaList(2)

Гость

Я бы сказал, что опускаемые вообще лишние (legacy), но среда - дура, не дает нормально оверлоудить процедуры проекта.

Ну, я смотрю, ты большой поклонник оверлоадинга

Делать перегрузку только ради того, чтобы обеспечить параметр по умолчанию, это круто

Перегрузку делают все же обычно когда требуется обеспечить разную/дополнительную функциональность, или когда обрабатывают одним аглоритмом разные по структуре/типу входящие параметры.

Удачи!
__________________________________
Владимир Якимченко
Написал: ClaList(2)

Гость

Ну а инициализация заданным значением не есть такая дополнительная функциональность. Вообще-то скорее наоборот, инициализация дефолтом д.б. основной функциональностью, в вот другим значением - дополнительной.

А что такого страшного в перегрузке? она ведь разрешается не в рантайм, а компилятором и линковщиком, и стоит лишнего Call взамен неявного If + подгрузка в стек лишнего параметра.

Собс-но я к этому пришел после того, как однажды мне пришлось вычленить в отдельную ветку каждую комбинацию "опускания". Получилось не очень читабельно, и я подумал: "А какого ...? Почему не...?"

или когда обрабатывают одним аглоритмом разные по структуре/типу входящие параметры.

Вот это действительно круто !!

WBR, Nick Tsigouro
Написал: ClaList(2)

Гость

В случае если "опускание" не сопровождается "значением по умолчанию" (только в этом случае можно получить ветвистость), то возможно перегрузка будет более эфективна и читабельна. Но я говорил, про наличие "значения по умолчанию", тут веток не бывает, и перегрузка, имхо, есть не оправанная трата ресурсов и вовсе не добавляет читабельности.

Кстати, это случай как раз использования "неинициализированных полей" (то, что в SQL называется NULL, а в perl/php - undef) - т.е. поле, не содержащее никакого значения, валидного для данного типа. Как бы не "значение по умолчанию" (например то, что делает Clear - 0 для числовых, пробелы для строковых), а "отсутствие значения". Иногда весьма полезно.

--
Best regards,
Maxim Yemelyanov,
Enigma Soft Company
phone: (057) 7177977
WEB: http://enigmasoft.com.ua
e-mail: clalist@enigmasoft.com.ua
ICQ: 12253836
Написал: ClaList(2)

Гость

Добрый день Николай !

Спасибо за оперативный отклик,

Если я правильно понял, то если, например, имеется некий ключ состоящий из трех полей:
\- Date
- NumDoc
- Draft_Flag

то в процедуре Browse ограничение SingleValue указывается только для поля Draft_Flag, а верхние два просто инициализируются ранее?

неужели так просто, а я тут коды пишу...(никогда не сталкивался, хватало и фильтра, а тут "большой" склад)....

Serguei Raguzini sergio_@mail.sochi.ru
Написал: ClaList(2)

Гость

Да. Шаблон в такой ситуации объявит два поля, сохранит в них текущие значеня Date и NumDoc и будет использовать их для построения фильтра.

WBR, Nick Tsigouro
Написал: ClaList(2)

Гость

Пример чего?

Цитирую: "Такое через опускаемый параметр вообще не сделаешь."
Вот и хотелось бы увидеть пример, подтверждающий это утверждение.

Сергей
Написал: ClaList(2)