Глюк с Omitted в функциях внутри класса

[Губин Игорь]

Т.е. независимо от того, что Вы фактически передаёте - параметры присутствуют всегда.
Пропущенные VALUE имеют значение пустой строки, а REFERENCE возвращают NULL.

Это же естественно. Непонятно, кто надеялся, что компилятор будет генерить массу различных вызовов?! Как бы не передавались параметры в функцию, по адресу или по значению, естественно передавать и обрабатывать NULL

[kreator]

Можно ещё воспользоваться overloading'ом

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

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

Идея была в том, что бы получить ошибку при обращении к несуществующему параметру.
И это сделать не удалось ... по крайне мере в актуальной тогда версии Clarion.

Я сомневаюсь в этом. Сталкивался с проблемой при обращении к отсутствующему параметру. Но уже не вспомню как ошибку получить. Или не ошибку, а неопределённость.

[Губин Игорь]

Если передавать опции и настройки в процедуру, то логичней будет передавать просто значение.

Ну не всегда. Скажем, передаётся некий числовой коэффициент от -бесконечности до +бесконечности. В то же время, когда этот коэффициент не определён, включается иной алгоритм обработки. Т.е. ни передача какого-то конкретного коэффициента, ни вариант значения по умолчанию тут не подойдут.

У меня это широко используется в шаблонах локализации: передаются тексты для контрола, заголовка, типов... (в том числе и пустая строка), а если текст не передали, то "смотри инструкцию"

[kreator]

Ну не всегда. Скажем, передаётся некий числовой коэффициент от -бесконечности до +бесконечности. В то же время, когда этот коэффициент не определён, включается иной алгоритм обработки. Т.е. ни передача какого-то конкретного коэффициента, ни вариант значения по умолчанию тут не подойдут.

Согласен, что есть такие случаи. Если коэффициент со значением "0" не катит, надо что-то делать. Вроде недавно писал. В SQL есть этот "NULL". По моему опыту в 95% случаев он не нужен, легче работать с чистым нулём. Но в 5% он сильно помогает. В Кларионе нет NULL. Хорошо, что хоть omittable переменные есть. Ну и в классах - если иной алгоритм обработки, то это может быть иной метод. По-моему логично.

[Губин Игорь]

Ну и в классах - если иной алгоритм обработки, то это может быть иной метод.

Не всегда. Когда это лишь фрагмент логики класса, а тем более, если разных алгоритмических путей несколько и неизвестно, какой потребуется...

[kreator]

если разных алгоритмических путей несколько и неизвестно, какой потребуется...

Как несколько? Вариантов всего два - omitted и not omitted.

[Губин Игорь]

Как несколько? Вариантов всего два - omitted и not omitted.

Это у блондинок с динозаврами всего два варианта, а в алгоритмах больше!

AFunc Procedure(Long,<Long>,Byte,<String>) ! В зависимости от сочетаний...

Кстати, как пример случая, не поддающегося overload без создания потенциальных ошибок: (<long>,<long>).

Надо признать, что классы, в отличие от некоторых шаблонов, у велосипедистов писались разумными программистами. У них, где я смотрел, нет ни одного подобного конфликта. Если возможна неопределённость, то они играют типами переменных (string <-> systemstringclass и т.п.)

P.S. Я сейчас большой спец в алгоритмах. только вчера объяснял почему "n + 2*n + 3*n + ... n*n" имеет сложность n*n*n

[finsoftrz]

ABC классы писались во второй половине 90-х. Тогда это был TopSpeed (считай, выходцы из jpi) и Дэвид Байлисс менеджер проекта. SV вроде как сильно их не перерабатывал, поэтому багов не успели насажать. Отношение к ABC классам разное встречалось, кто-то считает, что это одно из важных достижений в кларионе, кто-то писал, что это куча запутанного и плохо документированного кода, кто-то считает, что разработка ABC была ошибкой и явилась одной из причин быстрого ухода TopSpeed из бизнеса.

[finsoftrz]

Это у блондинок с динозаврами всего два варианта, а в алгоритмах больше!

Тут не очень понял, ты блондинок динозаврами назвал или динозавров блондинками?

[Губин Игорь]

Тут не очень понял, ты блондинок динозаврами назвал или динозавров блондинками?

Я об их встрече. Программисты, МАЛЧАТЬ!

[kreator]

Это у блондинок с динозаврами всего два варианта, а в алгоритмах больше!

AFunc Procedure(Long,<Long>,Byte,<String>) ! В зависимости от сочетаний...

Можно и больше ommitable-переменных использовать! Если взять, к примеру, 5, то вариантов будет 25. Это какая-то очень-очень специфика. Не готов что-то советовать. Если честно, такой подход мне не нравится. С двумя переменными (четыре варианта) ещё куда ни шло.
Есть вариант использовать побитовые операции, типа как в функции Message. И в случае использования классов, можно действовать через свойства класса. Для простоты понимания.

кто-то писал, что это куча запутанного и плохо документированного кода,

Я согласился бы с таким выводом. Как только залезаешь туда, думаешь - "А кто это сделал?"(©).

[Губин Игорь]

Можно и больше ommitable-переменных использовать! Если взять, к примеру, 5, то вариантов будет 25

Есть и такой вариант

Привожу пример: есть система локализации контролов. Каждый контрол, помимо, ?название, имеет
- Teхt/Format
- Msg
- Tip
(там хитрый алгоритм когда брать из файла, когда не брать, когда кричать об ошибке...)
Уже три
- файл откуда брать локализацию, если не по умолчанию
- файл по умолчанию, точнее, признак алгоритма его выбора
Ещё парочка
- признак разрешения корректировки файла локализации с указанием алгоритма выбора файла (отличается от файла по умолчанию)

Сколько там насчиталось? Ну хорошо, признаки можно сделать обязательными, хотя запятые считать задолбаешься. Файл для локализации можно сделать обязательным параметром, но это, потенциально, ведёт к трудно отлавливаемым ошибкам.

Можно, конечно, разбить это на кучу отдельных процедур, но тогда код будет расти и легко забыть вызвать нужную.

[Игорь Столяров]

Можно, конечно, разбить это на кучу отдельных процедур

Зачем каждую строку передавать как отдельный параметр ?
Можно сделать структуру (Group) со всеми параметрами и флагами и передавать только её одну.
А в методе спокойно разобрать содержимое структуры и проверить наличие нужных данных для локализации ...

[finsoftrz]

А еще лучше ссылку на класс.

[Губин Игорь]

Можно сделать структуру (Group) со всеми параметрами и флагами и передавать только её одну.

Можно, но не нужно. Это повлечёт множество переделок и множество проблем с излишними телодвижениями. К примеру, если требуется изменить только MSG или Text... Надо будет перед этим или заполнить эту группу текущими значениями или как-то её хранить или плодить кучу функций или работать с флагами... В общем - головной боли огромное количество, толку 0, структура кода превратится в нечто огромное и непонятное Т.е. имеет смысл лишь если отказ от Omitted будет носить вопрос принципа или веры.