См также фичи в develop.
Возможность задавать идентификатор корневому объекту фичи:
register_feature name="alfa" {
roota: column {
row {
text text="333";
button text=@roota->text;
}
}
Необходимо уметь иметь параметры у фич, то есть такая ситуация что фичам нужны собственные параметры, адресуемые не как константы, а по ссылкам. То есть что-то в духе circle background(color=@red).
Это приводит нас к необходимости создавать под-окружения. Но наверное возможны и другие варианты.
Из под-окружения необходимо делать доступ к родительскому окружению, куда мы прицепили фичу. Для этого мы делаем:
поле env.host -- указывает на саму env или на ту env, к которой текущая прицеплена в качестве фичи. Допом делаем поле env.hosted которое = true если мы в режиме с host-фичей.
Реализация F-FEAT-PARAMS как под-окружения приводит нас к: Необходимо доступ по путям-ссылкам к под-окружениям. (потому что тот же pipe создает link-и между компонентами по путям-именам). Например: circle backround(color=(compute1 | compute2))
Решение - даем имена objname:subenv-name через :. Возможная проблема - разные фичи натащут в под-окружение разных суб-фич с одинаковыми именами. Надо что-то с этим придумать, как вариант - строго следить за именами и в случае не-уникальности что-то делать (задавать новое имя + контекст новый для использования и по старому имени внутри вложенного дерева)
Очень частый наблюдаю на практике шаблон что надо что-то вычислить и присвоить как результат в параметр окружения. fpath: get_query_param name="file_path"; load_file path=@fpath->output; Сообразно идея оптимизации такая: load_file path=( get_query_param name="file_path" ); Это можно реализовать если обрабатывать в языке шаблон paramname=(exprenv) и например договориться что у exprenv берется поле output. Ну а саму эту exprenv можно сдаить в суб-фичи по аналогии с F-FEAT-PARAMS или еще как (можно и отдельно болтать, лишь бы lexicalParent был)
Хочется уметь передавать наборы окружений как параметры. Например для реализации идеи jetpack compose modifiers
- декораторы как цепочки в памяти. Решение - идея решения - это поддержать синтаксис something arg={ env; env; env } НО при этом не кидаться создавать эти env а запомнить их как дамп и передать его в arg. Это важно сделать именно потому что при вызове функций фич им уже надо знать, эта фича есть корневое окружение или эта фича есть прицепленное окружение.
Выснилась засада. если у нас 2 разные фичи.. в одном env.. порождают expr_env-ы... то получается что они их именуют одинаково [почему-то..]
вероятно самое правильное это - создавать subenv-пространство для каждого головного применения фичи (на головном окружении)..
но тогда неясно как адресовать эти субфичи извне...
ну пока применим что переименовывать субфичи.. но это тоже плохой вариант - на имя могут ссылаться вполне.. @design и @todo лучше решить. пока переименуем.
Необходим доступ к спец-полям объектов, таким как obj.host, из компаланга. Варианты решения: 1 - дублировать их в параметры. Минус - засоряем параметры. 2 - сделать if в links-are-objects. Минус - производительность, плюс только через ссылки доступ будет работать. 3 - сделать специальные аксессоры уже в ссылках аля Денис Перевалов, например: item=@obj.host и запись .host активирует вычисление по доступу к полю. Пока выбран вариант 1. update вариант 1 плохой т.к. некоторые опираются на getParamNames а там левое вот это все. Идем пока на вариант 2. и 2 идеи: сделать там таблицу, т.е. без иф. и вторая - ввести аксессор вида item=@obj->.host и это значит доступ к полю. Можно даже с несколькими точками. Но это получается без уведомлений.. и кстати так мы могли бы ссылаться на функции зато. и может это как-то соединить с параметрами которые через геттеры вычисляются (проект).
update - так-то надо все-таки в параметры, это гораздо удобнее. те че чилдрен реагировать и т.п. надо восстановить getParamNames чем мне не понравилось.
новые модификаторы - стабильные окружения, к которым присоединяются модифицируемые объекты (эти окружения уведомляются о присоединении)
при вставке нового модификатора в {{}}-дерево посылать ему уведомление о присоединении.
// update 2023-01 оказалось чухней и редким случаем; всегда только с1
Вычислять выражения вида alfa=(a;b;c;) здесь alfa=@c->output должно стать автоматом. При этом если в выражении есть if (который у нас порождает новые окружения) то результат его порождения тоже должен подхватиться. Из этого вытекает решение - создавать для () окружения типа computer которое подхватывает output своего последнего чилда.
update 2022-09. признано что ; это зло, но вместе с тем пока мы их не можем убрать не нарушив пайп. поэтому пока идет отказ от сложных выражений в (). это сделано на warning-aх. кроме того мысль на todo это убрать computer т.к. он становится не нужен, а добавляет лишние прослойки и задержки. если он нужен только для if, то и оставить его только для if.. либо пусть if выдает output - значение output порожденной ветки..
выяснилось что нам надо таки уметь задавать списку окружений параметры, и через это превращать их в функции. такие варианты: 1 some { |alfa| rect color=@alfa; } 2 feature "teta" { |sigma| .... } 3 some func={ |a b c| ... }
операция евал с записью вида @{: xxx :} вместо m-eval {: xxx :}