Редактировалось 1 раз(а), последний 2017-03-04 23:42:58

Именно так. Однако в новом пакете все будет с точностью до наоборот...

Редактировалось 1 раз(а), последний 2017-03-04 23:42:58

Это в том, который будет основан на потоковой кодогенерации. Там MathParse будет такой как сейчас в пакете WEB.

1) неправда в любом случае.
2) если используется doMathStr - это в любом случае парсинг

Не будет такой точки у MathParse. Поскольку элементы функционально полностью эквивалентны, то смысла в их паралельном сосуществование нет.

Ну-ну.
Вот только сначала парсинг, а потом вычисления - тоже оптимальней, чем всегда парсинг

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

А чего к этому вести - это и так понятно


И что теперь...
А если надо
У меня к примеру свой формульный калькулятор. Для чего еще надо - не знаю.
Но причин ликвидации парсера как элемента - недостаточно как-то.

Редактировалось 1 раз(а), последний 2017-03-04 23:42:58

что-то здорово смахивает на
если давления совсем пропало - это покойник.
Поподробнее можно? Насчет нулевых затрат производительности

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

[size=-2]------ Добавлено в 18:18

Парсера два. Причем один медленнее работает чем другой имея туже ф-ность. Чем не причина?


Элемент пакета WEB. Нечто вроде FormatString, но выполняемый на этапе кодогенерации