forum.clarionlife.net

kreator писал(а): ↑30 Апрель 2019, 11:07 Я как появилась возможность слезть с Легаси сразу слез. Вадим Синявский не говорил почему кинул шаблоны? Почему не стал ABC-шаблоны расширять?

Говорил. Не было финансовой подпитки. А сам он устроился работать в забугорную контору, где проект разрабатывается на abc.

Термина "легаси" у SV сейчас нет. Одно время они хотели похоронить линейку процедурных шаблонов и полностью перейти на abc. Но не получилось, видимо, много проектов было создано. Поэтому сейчас есть clarion и abc шаблоны. Обе линейки используют abc классы. ШВС остался отдельной веткой. При наличии множества наработок смысла с них слазить нет никакого. В стандартных abc много чего и сейчас нет, а много того, что есть - нафик не нужно. Идти по пути использования кучи шаблонов от сторонних разработчиков можно, но там свои сложности. Некоторые потом тратят кучу времени, чтобы избавиться от одних перейти на другие, которые поддерживаются. Такой себе зоопарк получается.

finsoftrz писал(а): ↑30 Апрель 2019, 11:35 Говорил. Не было финансовой подпитки.

А разве они были платные? А ABC развивать смысла не стало, там и так всё хорошо .

finsoftrz писал(а): ↑30 Апрель 2019, 11:46 Термина "легаси" у SV сейчас нет.

Как не назови. В Embeds осталась икона "Show Legacy Embeds".

finsoftrz писал(а): ↑30 Апрель 2019, 11:46 Обе линейки используют abc классы.

Где же Clarion-шаблоны используют ABC-классы? Если только в самом минимальном виде. Но вот мой недавний опыт попробовать прикрутить Превьювер-класс к старым репортам окончился крахом. Программа падает на входе в процедуру, такое ощущение, что не нравится декларация класса. Сейчас уже не вспомню, но по-моему была попытка использовать EIP, которая тоже ни к чему хорошему не привела.

По поводу стандартных clarion шаблонов надо у Игоря Губина спросить, он с ними работает, квалифицирует подробнее.
Под процедурную линейку только ленивый шаблонов не писал. Все достаточно просто и понятно. Под abc все заметно усложнилось. Кто из использующих abc на этом форуме активно пишет шаблоны? Я так понимаю, большинство даже и не пробовали. Или по мелочи.

finsoftrz писал(а): ↑30 Апрель 2019, 12:58 По поводу стандартных clarion шаблонов надо у Игоря Губина спросить, он с ними работает, квалифицирует подробнее.
Под процедурную линейку только ленивый шаблонов не писал. Все достаточно просто и понятно. Под abc все заметно усложнилось. Кто из использующих abc на этом форуме активно пишет шаблоны? Я так понимаю, большинство даже и не пробовали. Или по мелочи.

В случае ABC для себя достаточно написать/подправить класс. А шаблон в этом случае уже не столь важен. А если делаешь класс на продажу, то без шаблона не обойтись. Да и то, если есть много настроек. А так во многих случаях это просто описание/инициализация класса и вызов методов. Я бы сказал, что всё упростилось.

И как подправить класс, если нужно квалифицировать структуры базы данных по пользовательским опциям словаря? В общем, вопрос риторический. Можно и совсем без шаблонов, как в других средах. И без словаря. И без клариона. Без шаблонов в кларионе кайфа совсем никакого нет...

Ещё интересный момент из жизни BindExpression.

Нигде в описании не сказано, но в реальности BindExpression() устанавливает код ошибки аналогично Evaluate().
И вроде это хорошо, но дьявол, как обычно, скрывается в деталях …

Предположим, нам нужно забиндить некие макросы, используемые для расчёта формулы.
Есть условия, при которых макрос может быть не задан. Тогда:
Хотя, в данном случае, некорректно обрабатывает пустое значение именно Evaluate(), a не BindExpression() ...

Игорь Столяров писал(а): ↑15 Май 2019, 8:53! Результат = "", что говорит о неправильной формуле

ИМХО, для Evaluate это не ошибка. Это не выражение, и не формула. Просто пустая строка.

kreator писал(а): ↑15 Май 2019, 11:19Это не выражение, и не формула.

Никто и не против. Но хотелось бы как-то одинаково …
Потому, что для BindExpression() та же пустая строка - уже явная ошибка.

Поэтому выражение, в котором может быть пустое значение для Evaluate() и BindExpression() приходится обрабатывать по разному.
Это не есть большая проблема, просто видимо ещё одно место, где что-то убирали костылями в RunTime Clarion.

Игорь Столяров писал(а): ↑15 Май 2019, 12:32 Никто и не против. Но хотелось бы как-то одинаково …

ИМХО, никто не обещал. Где-то в хелпе проскакивают фразы об их подобной работе, только и всего. Вы же используете evaluate после bindexpression? Логично ошибку отрабатывать для bindexpression. А evaluate уже на автомате должен что-то выдать после bindexpression.
Уже стёрлось из памяти, но bindexpression ввели достаточно поздно. И, наверно, для определённого круга задач. И может быть изначально не стояла задачи унификации. Может быть смущает название функции - bindexpression, bind? Как Java и JavaScript. Несмотря на похожесть названий, абсолютно разные истории.

bindexpression для преобразования выражений в промежуточный p-код, чтобы каждый раз не делать синтаксический разбор. Такое сейчас во всех скриптовых языках используется для ускорения интерпретации.

finsoftrz писал(а): ↑15 Май 2019, 14:06Такое сейчас во всех скриптовых языках используется для ускорения интерпретации.

Я Вам больше скажу ! В Clarion 2.1 тоже был пре-процессор, трансляция шла в некий промежуточный код, который
можно было выполнять или ликовать в EXE … Но конкретно bindexpression() видимо главная фишка в замене вызовов процедур
по имени на адреса. Т.к. ощутимый выигрыш скорости (в разы) именно в выражениях с вызовом функций.

Помню про Clarion 2.1. Много на нем хороших вещей было понаписано. Я там никогда линковку в exe не делал. Исполнял pro файлы (тот самый компактный байт-код). Баррингтон писал, что переход на компилируемый код (exe и dll) дал прирост скорости в 5-6 раз относительно байткода. Для того времени это было серьезно. Да и даже сейчас маркетологи стесняются поминать слово "интерпретация", предпочитая более благозвучное "управляемый код". Эхо времен.

finsoftrz писал(а): ↑15 Май 2019, 15:03Эхо времен.

Гы ! Спираль истории сделал оборот и вернулось к тому же на новом уровне.
Все современные системы разработки по сути - интерпретаторы, выполняемые на неком системонезависимом "процессоре" …
Ликовать в код конкретного аппаратного процессора - немодно, единой системы кода нет, Вавилон продолжается …

Из компилируемых, кроме клариона, есть еще дельфи. Тоже не мейнстрим. Есть еще достаточно многочисленная популяция, которая давно пишет на сях и не парится. Ну, может еще кобол и некоторые малораспространенные компиляторы традиционных си и паскаля. Наиболее популярные (c#, джава, питон, вебовские языки) интерпретаторы. Тот же sql.
У меня общее впечатление, что те, кто пишет на компилируемых языках, как-то лучше понимают, что они делают...