forum.clarionlife.net

Игорь Столяров писал(а): 06 Май 2024, 17:27 Т.е. независимо от того, что Вы фактически передаёте - параметры присутствуют всегда.
Пропущенные VALUE имеют значение пустой строки, а REFERENCE возвращают NULL.

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

Игорь Столяров писал(а): 06 Май 2024, 16:29

kreator писал(а): 03 Май 2024, 16:47 Можно ещё воспользоваться overloading'ом

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

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

Игорь Столяров писал(а): 06 Май 2024, 17:27 Идея была в том, что бы получить ошибку при обращении к несуществующему параметру.
И это сделать не удалось ... по крайне мере в актуальной тогда версии Clarion.

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

kreator писал(а): 06 Май 2024, 21:40 Если передавать опции и настройки в процедуру, то логичней будет передавать просто значение.

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

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

Губин Игорь писал(а): 07 Май 2024, 10:55 Ну не всегда. Скажем, передаётся некий числовой коэффициент от -бесконечности до +бесконечности. В то же время, когда этот коэффициент не определён, включается иной алгоритм обработки. Т.е. ни передача какого-то конкретного коэффициента, ни вариант значения по умолчанию тут не подойдут.

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

kreator писал(а): 07 Май 2024, 19:27 Ну и в классах - если иной алгоритм обработки, то это может быть иной метод.

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

Губин Игорь писал(а): 07 Май 2024, 20:22 если разных алгоритмических путей несколько и неизвестно, какой потребуется...

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

kreator писал(а): 07 Май 2024, 22:30 Как несколько? Вариантов всего два - 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

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

Губин Игорь писал(а): 08 Май 2024, 9:49 Это у блондинок с динозаврами всего два варианта, а в алгоритмах больше!

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

finsoftrz писал(а): 08 Май 2024, 10:20 Тут не очень понял, ты блондинок динозаврами назвал или динозавров блондинками?

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

Губин Игорь писал(а): 08 Май 2024, 9:49 Это у блондинок с динозаврами всего два варианта, а в алгоритмах больше!

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

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

finsoftrz писал(а): 08 Май 2024, 10:12 кто-то писал, что это куча запутанного и плохо документированного кода,

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

kreator писал(а): 08 Май 2024, 13:09 Можно и больше ommitable-переменных использовать! Если взять, к примеру, 5, то вариантов будет 25

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

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

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

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

Губин Игорь писал(а): 08 Май 2024, 13:27 Можно, конечно, разбить это на кучу отдельных процедур

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

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

Игорь Столяров писал(а): 09 Май 2024, 17:07 Можно сделать структуру (Group) со всеми параметрами и флагами и передавать только её одну.

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