Вверх ↑
Администрация
Ответов: 15294
Рейтинг: 1518
#1: 2021-01-13 16:19:37 ЛС | профиль | цитата
sаmakacd писал(а):
Или неужто какой-нибуть полиморфный контейнер можно было описать в sha в виде обычного MultiElement-a?

sаmakacd, возможно я не совсем понимаю, о чем именно идет речь, говоря о зависимости формата хранения данных и их отображения на экране. Что я имею ввиду: вот есть у вас полиморфный контейнер, пусть в файле он хранится у нас как

PolyElement {
SubElementClass1 {
....
}
SubElementClass2 {
....
}
}

Т.е. мы создали полиморфный контейнер и в нем два наследники с разными классами SubElementClass1 и SubElementClass2. Вот это описание накладывает какие-то ограничения на то, как этот контейнер должен выглядеть в среде? Абсолютно нет. Вы можете отобразить его как вкладки:



Вы можете при входе внутрь PolyElement сначала нарисовать все сабконтейнеры, а уже при клике на нужный отобразить схему в нем:



А можете ничего вообще не отображать и рисовать его как обычный мультиэлемент, но в свойствах PolyElement дать выбрать тот класс, в который попадает пользователь при входе внутрь контейнера. Или придумать сотню других способов управления и отображения, каждый из которых будет совершенно не похож на предыдущий. Именно об этой независимости отображения от внутреннего устройства я и говорю и ограничивать его нет совершенно никакого смысла. А вот формат хранения есть - он как раз должен быть стандартизирован и не допускать никаких вольностей.

Второй тип стандарта, потребность в котором стала очевидна, но который так и не успели реализовать - это стандарт на реализацию базовых элементов любого пакета. Что это значит? У нас в каждом пакете есть около сотни одинаковых элементов для работы с примитивами типа строк, матриц, массивов, чисел, потоками данных т.д. и вот все они по хорошему должны быть стандартизованы. Берем мы скажем элемент конкатенации строк и создаем стандарт: обязательное название элемента StrCat, он должен содержать один метод с названием doStrCat с произвольным количеством аргументов Str и одно событие с названием onResult. Так же в элементе должно быть свойство с названием Mask, которое представляет из себя строку, в которой все вхождения %Str№% заменяются на значения соответствующих аргументов. Жестко регламентировав таким образом базу вы добьетесь того, что большие куски всех схем будут переносимы без правок между пакетами и будут там совершенно правильно работать. Вот это и надо прорабатывать.

sаmakacd писал(а):
что есть атмосфера противостояния на счет внесения изменений в визуальный язык.

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

Noor писал(а):
Если делфи умер то почему бы не собрать ядро на каком на другом корневом языке например С или подобный, а уже пакеты подключать любые под любые платформы. Да и само ядро компилировать под любую ОС.

Noor, C++ это хороший вариант, однозначно лучше, чем Delphi. Однако использование в WEB все же выглядит более перспективным, потому что позволяет делать множество из тех вещей, которые в настольных приложениях сделать нельзя.

Netspirit писал(а):
И на C собрали и на C#, да что-то разработчиков от этого не прибавилось.

А кто-то этих разработчиков звал/искал? Или как вы себе этот процесс представляете - выкладываешь ты на условный github ПО на С++/C# и на следующий день у тебя 100 контрибьютеров, готовых каждый день по десятку пул реквестов слать с правками и доработками?
карма: 26
0