Илья Ермаков писал(а):
P.S. Только такое ощущение, что как только фундаментальность штуки прочувствуется, станет ясно, что всё многообразие возможных примений конкретным средством не покрыть. И прошивать его в язык не стоит, если всё равно перереализовывать надо будет под ситуацию.
Хм... Как бы это объяснить, что
без языка не получится...
Ну давайте я попробую говорить "аки теоретик", хотя это и не моя сильная сторона.
Предположим, что под типом мы понимаем множество значений, которое могут принимать представители этого типа.
Тогда структура из двух типизированных полей - это произведение двух множеств (в том смысле произведение, что является множеством пар представителей из соответствующих множеств)
Далее, имеем отношение эквивалентности на этом "произведении". Которое помещает в один класс эквивалентности структуры, у которых эквивалентны тип поля obj, и тип первого аргумента поля proc. Еще раз замечу, что IS - не катит, он не есть отношение эквивалентности.
Так вот, нужный нам тип - это множество именно классов эквивалентности над этим множеством-произведением.
Как бы, эдакая "одномерная линия" в "двухмерном" пространстве-произведении (если исходить из глупейшего предположения, что исходные множества были представимы одномерным пространством).
Ну и что получается? Произведение множеств - имеет адекватный "конструктор типа" в Языке. А выделение "множества классов эквивалентности" - нет.
Поэтому и думаю, что имеющимися средствами не обойтись. Собственно, тут персонально моих мыслей вообще немного. Больше наблюдений, чем мыслей. Например такое наблюдение:
А сделавши, говорят: "ну и фигня же получилась", и начинают делать QTПро многообразие...Не думал, что предлагал средство от всех болезней
Достаточно, мне думается, чтобы на каком-то заметном множестве задач - давал решение, которое по эффективости (в т.ч., и умственных затрат разработчика) не достигнуть уже имеющимися средствами.
У меня самого куча вопросов возникает, если размышлять "о совершенстве Мира". Не таких, что не имеют решения, а таких, что имеющиеся решения не очень вдохновляют.
Есть разработчик объекта- отправителя сообщей. А есть - объекта-получателя.
И было бы правильно (надежно), что бы у них вообще не было потребности знать как о проблемах друг-друга, так и о проблемах того, кто будет "сшивать" их творчество.
Ну а кто тогда будет определять типы сообщений....
Есть Думатель, который может чего-то делать (вычислять, интегрировать, дифференцировать, и т.п.) с текстовыми формулами. Его Автор такие методы и написал, как сам понимал. И знать не хотел, что это будут сообщения от таймера, от полей ввода, или вообще запрос по интернету.
Соответственно, и автор какого-нибудь визуального контролла понятия не имел, что сообщения он будет отправлять какому-то там Решателю
А кто будет иметь ??? Кто будет заводить типы сообщений, или стыковать сигнатуры слотов с сигналами ???
((в смысле, я не прошу решения задачи, мне известны какие-то))
Как-то надо влезать в уже построенные ящики, или надстройки делать...
Все время как-то получается: хочешь надежность - жертвуй эффективностью
А я хочу И надежность, и НЕ жертвовать
Ну это так - отвлекся..........