Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, mkizub, Вы писали:

M>>Проблемы начинаются когда происходить export/import в текст.
S>Нет. Проблемы начинаются сразу, как только я нажимаю Save. Я говорю не про roundtrip engineering, а про банальную совместную работу над розовской моделью. Остальные рассуждения, основанные на неверных постулатах, поскипаны.

S>P.S. Посмотри на то, как работают class diagrams в Visual Studio. Всё прекрасно работает без всяких "читать не сможешь" и "представления в AST".

У меня нет VS. По причине линуховской операционки, и вообще.
Так ты сделай там два класса с одним именем, и сохрани/восстанови. Расскажи как они справились.

Здравствуйте, Cyberax, Вы писали:

C>Естественно, я имею в виду осмысленный текст. Типа отформатированого XML, который ПРЕКРАСНО кладётся в репозиторий.

бинарники тоже там отлично лежат

C>И какие тут непреодолимые проблемы?

посмотри на мой пример в http://rsdn.ru/forum/message/2974514.1.aspx

Автор: mkizub
Дата: 03.06.08

Здравствуйте, Severn, Вы писали:

S>Ага, о том и речь. Хорошо когда абстрактное представление отделено от редактируемого. но нашему парню с wise-ом от этого не легче
S>Т.е. практика показывает, что сохранять все равно лучше опять таки в чем-нибудь human-readable. Чтобы когда среда в конец заглючит, открыть старый добрый FAR ....

Оно конечно. Но невозможность редактирования MS Word-овских документов FAR-ом сыграла очень мало значения в
распространении этого MS Word-а
Нужен некий единый стандарт для предствления данных в структурных редакторах.
И под этот стандарт напишут и репозитории и diff/merge, и редактировать его можно будет
целой тучей редакторов и IDE.
Так же как принцип текста (текстового синтаксиса) — является центром некоей экосистемы средств разработки
и программистов, так и для структурного редактирования надо создать свою экосистему. Это процесс долгий
и трудный, но по моему глубокому убеждению — неизбежный.

Здравствуйте, mkizub, Вы писали:

M>Это процесс долгий и трудный,
И нафиг не нужный ибо текст ничему не мешает.

Здравствуйте, Sinclair, Вы писали:

M>>Потом в репозитории сделали мержинг исправлений. Делайте ваши ставки
S>Во-первых, в большинстве реальных применений подобной хрени не встречается. Потому что физического смысла переименовывать васю в петю нет.
S>Во-вторых, те проблемы, с которыми сталкивается text-based XML мерджер, очевидны и разрешимы. Техники продвинутого diff & merge для XML существуют и уже давно.

Ага. Например проект harmony, который через нечто называемое ими "линзы" задаёт преобразования, а
фактически задаёт семантическое значение данным в XML. И после этого уже мержит.
То есть эмулирует для текста то, что для AST дерева уже задано — семантическое значение узлов/данных.
Ваше "существуют и уже давно" — это и есть зачатки того, о чём пишет Фаулер.

Здравствуйте, WolfHound, Вы писали:

M>>Это процесс долгий и трудный,
WH>И нафиг не нужный ибо текст ничему не мешает.

Совсем ничему?
Давай на примере Nemerle.
Если бы компилятор Nemerle поддерживал C#-повский синтаксис — он разве не получил бы большего распространения?
А закатывание неудобного для Nemerle синтаксиса в строки — это разве не мешает?
Пока это какие-то примитивные синтаксисы, то ещё сходит. А если вы захотите обеспечить
полноценную поддержку SQL запросам, XPath синтаксису и пр. — на каждый из них вам надо будет
писать отдельный парсер и т.п.

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

Здравствуйте, mkizub, Вы писали:

M>Ага. Например проект harmony, который через нечто называемое ими "линзы" задаёт преобразования, а фактически задаёт семантическое значение данным в XML.
Линзы это однозначные двусторонние преобразования.
Те для любой линзы (lens a <=> b) при любых значениях A верно что A == inv(lens)(lens(A))
ВСЕ!
Никакой семантики.

Здравствуйте, mkizub, Вы писали:

WH>>И нафиг не нужный ибо текст ничему не мешает.
M>Совсем ничему?
Совсем.
Все проблемы лежат в модели системы.

M>Давай на примере Nemerle.
M>Если бы компилятор Nemerle поддерживал C#-повский синтаксис — он разве не получил бы большего распространения?
А если бы в С++ были продолжения?
А если бы у бабушки был...?

M>А закатывание неудобного для Nemerle синтаксиса в строки — это разве не мешает?
Это политические проблемы.
Если продавят более мощьные лексичиские макры то этого не будет.

M>Пока это какие-то примитивные синтаксисы, то ещё сходит.
M>А если вы захотите обеспечить полноценную поддержку SQL запросам,
Какой именно диалект? И они далеко не только синтаксисом отличаются.
M>XPath синтаксису и пр. — на каждый из них вам надо будет писать отдельный парсер и т.п.
А тебе семантические узлы и редакторы к ним.

M>У Nemerle нет будущего. Не в краткосрочной перспективе, а в долгосрочной.
У твоей сумаде тем более ибо любой пионер сможет сделать дерево которое само себе протеворечит.
Причем далеко не всегда эти противоречия можно будет даже засечь...
Система будет просто делать совершенно непонятные действия.

M>Именно потому, что он пытается сидеть на двух стульях, сочетать мета-программирование и текстовый синтаксис.
Это не проблема.
Проблемы немерла в другом.

M>Да и подход, когда вся семантика нового семантического понятия выражается лишь макросом, который задаёт rewriting этого понятия через старые — слишком ограничивает возможности мета-программирования.
А если их не ограничивать то в одно дерево обязательно попытаются засунуть деструкторы (или любую другую модель детерминированной финализации) и продолжения.
И это только один из вариантов все поломать.

Здравствуйте, mkizub, Вы писали:

M>и трудный, но по моему глубокому убеждению — неизбежный.

Если ты не заметил, то M$ эту экосистему уже давно и упорно создаёт. Лна называется XML...

Здравствуйте, WolfHound, Вы писали:

M>>Ага. Например проект harmony, который через нечто называемое ими "линзы" задаёт преобразования, а фактически задаёт семантическое значение данным в XML.
WH>Линзы это однозначные двусторонние преобразования.
WH>Те для любой линзы (lens a <=> b) при любых значениях A верно что A == inv(lens)(lens(A))
WH>ВСЕ!
WH>Никакой семантики.

Линзой задаётся семантика, а не в семантике линзы семантика конкретного XML-я.
Они в своих примерах с той-же телефонной книжкой это показывают.
Задают линзу, которая указывает, что уникальным идентификатором для записи
в телефонной книжке является имя человека. И когда секретарша правит имя
Васи на Петю, то при помощи этой линзы мержингу задаётся, что фактически
запись для Васи удалена и добавлена новая запись для Пети. И мержинг
в этом случае скажет — одна секретарша удалила запись для Васи, а другая
поменяла в этой записи номер телефона. Вот вам конфликт. А не будет
заменять Петин телефон Васиным. Благодаря семантике конкретного XMLя
обозначенной конкретной линзой. Что тебе тут непонятно?

Здравствуйте, mkizub, Вы писали:

M>Линзой задаётся семантика, а не в семантике линзы семантика конкретного XML-я.
Причем тут вобще XML?

M>Они в своих примерах с той-же телефонной книжкой это показывают.
M>Задают линзу, которая указывает, что уникальным идентификатором для записи в телефонной книжке является имя человека.
M>И когда секретарша правит имя Васи на Петю, то при помощи этой линзы мержингу задаётся, что фактически запись для Васи удалена и добавлена новая запись для Пети.
Там просто создают линзу которая переводит одно значение в другое.
И все.
При этом тойже линзой можно провести обратное преобразование.

M>И мержинг в этом случае скажет — одна секретарша удалила запись для Васи, а другая поменяла в этой записи номер телефона.
M>Вот вам конфликт. А не будет заменять Петин телефон Васиным. Благодаря семантике конкретного XMLя обозначенной конкретной линзой.
Чтобы тебе было понятно:
Есть линза которая переводит url encoding в xml encoding и обратно
url2xml : lens UrlEncodedText <=> XmlEncodedText

теперь если в эту линзу засунуть что-то является валидной url encoded строкой то мы получим валидную xml encoded строку.
А если мы туда засуним строку в которц есть символы не допустимые для url encoded строки то мы получим по башке.
ВСЕ!

В твоем случае у нас есть вот такая вот веселая линза:
ТекстСВасей <=> ТекстСПетей
Эта линза заменяет имя Вася на имя Петя и обратно.

И вторая линза:
ТекстСВасей <=> ТекстСВасей
Эта линза меняет один телефон на другой и обратно.

Очевидно что если к тексту применить сначала первую линзу, а потом вторую будут проблемы.

Где ты тут нашол семантику ХЗ.

M>Что тебе тут непонятно?
Что тебе тут непонятно?

Здравствуйте, mkizub, Вы писали:

C>>Естественно, я имею в виду осмысленный текст. Типа отформатированого XML, который ПРЕКРАСНО кладётся в репозиторий.
M>бинарники тоже там отлично лежат
До первого конфликта.

C>>И какие тут непреодолимые проблемы?
M>посмотри на мой пример в http://rsdn.ru/forum/message/2974514.1.aspx

Автор: mkizub
Дата: 03.06.08

Я не вижу в чём там проблема.

Здравствуйте, mkizub, Вы писали:

M>Если бы компилятор Nemerle поддерживал C#-повский синтаксис — он разве не получил бы большего распространения?
Не получил бы — проблема в семантике.

Для Nemerle, AFAIR, были несколько вариаций синтаксисов.

M>А закатывание неудобного для Nemerle синтаксиса в строки — это разве не мешает?
Нет.

M>Пока это какие-то примитивные синтаксисы, то ещё сходит. А если вы захотите обеспечить
M>полноценную поддержку SQL запросам, XPath синтаксису и пр. — на каждый из них вам надо будет
M>писать отдельный парсер и т.п.
И что? Парсер-то всё равно придётся писать, хоть и в виде адаптера для древесной системы.

Здравствуйте, mkizub, Вы писали:
M>У меня нет VS. По причине линуховской операционки, и вообще.
Ну так подними ее в VM. А то ты тут свою IDE пытаешься изобрести, при этом ничего про реальные IDE не знаешь.
M>Так ты сделай там два класса с одним именем, и сохрани/восстанови. Расскажи как они справились.

Здравствуйте, Sinclair, Вы писали:

S>Ты с чем несогласен-то? С тем, что текстовость формата не влияла на производительность дельфи приложения даже на железе образца 1995 года?

С какой версии Дельфи формат описания форм стал текстовым?

Здравствуйте, Andrei F., Вы писали:
AF>С какой версии Дельфи формат описания форм стал текстовым?
Насколько я помню, с 6й. Имеется в виду — формат хранения. Редактор форм в текстовом формате был как максимум в тройке.

Здравствуйте, WolfHound, Вы писали:

WH>Что тебе тут непонятно?

Мне непонятно твоё употребление слова "семантика".
В словаре это слово расшифровывается как "значение", "понимание" обозначений.
Эрго — семантика существует только при наличии понимателя этих обозначений.
У понимателя семантика, а не сама по себе и не у обозначений, не у знаков и символов.
Это символы чего-то для наблюдателя, для читающего.

Соответственно, линзы задающие однозначные преобразования в какую-то другую форму и обратно,
задают семантику (значение) для некоего понимателя (в нашем примере — мержера),
поскольку эта новая форма имеет другую семантику для этого понимателя.
Простой пример с XML-ем и текстом — для XML-я формы "<tag/>" и "<tag></tag>"
имеют одну и ту-же семантику, а для текста (редактора, diff-а и прочих текстовых
"понимателей") это семантически разные вещи.

В harmony они линзами преобразовывают XML (или другой иерархический формат данных)
в некое внутренне своё представление, понимаемое их мержером. Этим они и задают
семантику конкретного XML-я для своего мержера. Тот производит слияние изменений
и через линзы делается обратное преобразование, задающее семантику для XML
парсера и прочих XML-евских тулзов.
Преобразование XML-я во внутреннее представление можно сделать по разному, и это
задаст разную семантику для мержера, варьируя которую мы задаём семантику
для себя. Скажем,
<phonebook>
<name>Вася</name>
<phone>123</phone>
</phonebook>
может быть преобразовано в
phonebook:{ name:{Вася} phone:{123}}
а может быть преобразовано и в
phonebook:{ name:{Вася phone:{123}}}
что будет для мержера иметь совершенно разную семантику, в первом случае name и phone
независимые данные, а во втором случае phone является под-элементом name.
В первом случае он будет мержить name и phone независимо, а во втором случае он
при изменении name (фактически удалении узла с name:Вася и вставки узла с name:Петя)
будет удалять и все под-узлы удалённого узла.
Для нас, секретарш и программистов, второе поведение мержера является правильным,
вторая модель трансформации данных является правильной — с точки зрения нашей семантики,
нашего понимания данных в phonebook. Таким образом эта линза и задаёт семантику.

SymADE в данном случае отличается от других средств программирования тем, что у него
уже задана стандартная внутренняя форма, внутренее представление. И больше того, программа
и хранится в виде внутреннего представления. Скажем, phonebook уже задан и хранится
в виде phonebook:{ name:{Вася phone:{123}}}, а не phonebook:{ name:{Вася} phone:{123}}.
Этим и задаётся семантика узлов, одинаковая для всех "понимающих" эту программу — редактора,
компилятора, отладчика, репозитория исходников и diff/merge утилит и т.д. и т.п.

Здравствуйте, mkizub, Вы писали:

M>В harmony они линзами преобразовывают XML (или другой иерархический формат данных)
M>в некое внутренне своё представление, понимаемое их мержером.

Сделав ложную предпосылку, врядли ты получишь что-либо вменяемое. Линза по сути есть лишь пара функций, преобразующих данные (какие угодно, не обязательно иерархические) "туда и обратно".
Для тебя функция f(x)=x+1, тоже приводит x сначала к какому-то внутреннему представлению, прежде чем единицу прибавить?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, mkizub, Вы писали:
M>>У меня нет VS. По причине линуховской операционки, и вообще.
S>Ну так подними ее в VM. А то ты тут свою IDE пытаешься изобрести, при этом ничего про реальные IDE не знаешь.
M>>Так ты сделай там два класса с одним именем, и сохрани/восстанови. Расскажи как они справились.
S>

Ну нет так нет.

Здравствуйте, Курилка, Вы писали:

M>>В harmony они линзами преобразовывают XML (или другой иерархический формат данных)
M>>в некое внутренне своё представление, понимаемое их мержером.

К>Сделав ложную предпосылку, врядли ты получишь что-либо вменяемое. Линза по сути есть лишь пара функций, преобразующих данные (какие угодно, не обязательно иерархические) "туда и обратно".

Я говорю о реализации мержинга иерархических данных, в частности XML, в harmony, а не о функциях и линзах вааще.

К>Для тебя функция f(x)=x+1, тоже приводит x сначала к какому-то внутреннему представлению, прежде чем единицу прибавить?

Да. Функций "вааще", "самих по себе" не существует. Для тебя это новость, да?
Функции существуют в нашем воображении, в понимании их интерпретаторами или компиляторами и т.д.
А то, что ты нарисовал — это не функция, это текст, последовательность букф (впрочем, тоже существующая
только в нашем воображении, а для компа это, например, набор чисел, для электронщика это набор
состояний транзисторов в памяти комп и т.д.).
И я и ты, и компиляторы, и кто угодно — преобразует текст "f(x)=x+1" в некое внутренее представление,
и потом занимается преобразованием этого внутреннего представления согласно неким своим правилам.
Кроме тулзов работающих с текстом как таковым, вроде regexp-ов, но у них и нет такого понятия как
"функция f(x)", и никуда они единицу не прибавляют. Нечем, не умеют, у них нет такого понятия как
функция или сложение.