Здравствуйте, AndrewVK, Вы писали:
AVK>В приведенном куске нет практически никакого системного кода, он весь аккуратно спрятан. А вызовы типа DeleteObjects очевидны и недвусмысленны.
Те ты спроектировал всю систему. И знаешь, что там за всеми этими функциями происходит.
Какой код и по каким моделям генерируется.
У тебя есть вся информация.
У нас нет.
Поэтому тебе все понятно.
Но никто тут ничего по этому куску кода не поймет.
Ты бы и сам ничего не понял, если бы не был архитектором всего этого дела.
Я тоже с первого взгляда пойму, что написано на ДСЛ который сам делал.
Так что то, что ты понимаешь этот кусок кода, ничего не значит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Те ты спроектировал всю систему. И знаешь, что там за всеми этими функциями происходит.
Нет, не знаю. Потому что почти все функции в примере — прикладные, а не системные. Системный код занимается организацией вычислений, и в приведенном отрезке его не видно. И к DSL он уж точно отношения не имеет.
WH>Какой код и по каким моделям генерируется. WH>У тебя есть вся информация.
Эта информация для понимания кода не нужна. Совсем.
WH>Я тоже с первого взгляда пойму, что написано на ДСЛ который сам делал.
Так не DSL же, а обычный C#, в том то все и дело.
WH>Так что то, что ты понимаешь этот кусок кода, ничего не значит.
Значит значит. Попробуй привести кусочек, который ты не можешь понять, и объясни что ты в нем не понимаешь.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?
AVK>...
Этот код никто кроме авторов понять не может. У вас там явно есть какая-то внутренняя модель с которой вы взаимодействуете по средствами своего АПИ. Чтобы понять код нужно не только знать АПИ, но и понимать устройство модели.
Лучше опиши используемую у вас модель и то что с ней делает этот фрагмент кода. Тогда можно будет что-то сказать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Vain, Вы писали: V>>Как я сказал уже это от базы данных зависит. Как вы к примеру собираетесь через SQL управлять реестром винды? Или файловой системой? А это ведь тоже база данных. S>Хорошо, раз вам неочевидно, я разжую ещё подробнее: через SQL проще управлять реляционными базами данных.
Я фигею моя деревня. Это вам я пытался объяснить битый час. У SQL своя ниша и он далеко не панацея при работе с базами данных.
S>>>Совершенно неважно то, что сами базы данных — это большая и сложная область. Мы сейчас не сравниваем объём предметных областей. Мы сравниваем удобство и простоту различных языков для работы в этих областях. V>>Попу с пальцем сранивать бесполезно. S>Ну, если вы хотите на таком уровне сравнивать, то я не понимаю смысла вообще дальше общение продолжать. S>А если хотите по делу — смотрите рядом комментарии коллеги vdimas-а. Он наглядно продемонстрировал, в какой ужос превращается SQL при попытке заменить его на C++. К слову, на чистом C всё будет ещё на порядок хуже.
Тоже самое может произойти и с С++ при попытке заменить его на SQL. Примеры я уже привел: реестр, файловая система и т.д.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, VladD2, Вы писали:
VD>Ты занимаешься демагогией.
Я бы сказал, вы все тут молодцы демагогией в той или иной степени занимаетесь Потому что обсуждение терминов почти всегда оно и есть. Правда, стоит заметить, что, почему то, топики с участием netch80 явно чаще среднего по больнице на обсуждение терминов скатываются.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
K>>2.1. Я не являюсь специалистом в создании DSL.
AVK>А таких людей вообще — просто считанное количество. That's the problem.
Это вопрос образования и материалов по теме.
K>>2.2. У меня нет удобных средств написания DSL.
AVK>Причем тут средства? Я не прошу тебя написать парсер и анализатор DSL, я прошу показать, как DSL будет выглядеть.
Дык если у человека будет средство, то он сможет найти красивое решение методом проб и ошибок (как это делается без ДСЛ-ей).
K>> Поэтому я с такой надеждой смотрю на N2, и желаю проекту успеха.
AVK>Удивительное дело — только что ты написал, что проблема то далеко не только в средствах. И N2 тебе тут ничем не поможет. Понимаешь, на практике я вижу, что даже сам факт осознания того, что для парсинга нужно грамматику описать для подавляющего большинства программистов отсутствует. Они неспособны даже формально описать существующий язык. Что уж говорить о сочинении собственной грамматики с нуля.
Удивительное дело. Тут на форуме собираются вполне грамотные программисты, которые сами-то знают как правильно решать задачи, но о всех окружающих отзываются как об обезьянах. Получается по одиночки все гении, но стоит им собраться в одну компанию, как они превращаются в стадо обезьян .
AVK>И N2 необходимость создания этой самой грамматики отнюдь не отменяет, он упрощает только последующие шаги.
Ну, да. Чуда не случится и обезьяна с гранатой не станет в одночасье десантником. Но на свете много не глупых людей которые не применяют ДСЛ-и широко только потому, что нет достаточно удобного средства и нет описания как это можно сделать.
K>>Пока что я пишу примерно такой же код.
AVK>Ну так покажи — какой код ты хотел бы писать.
Это нельзя сделать по твоему фрагменту. Из него не ясна модель. А без этого разговаривать не о чем.
K>>Просто, мне кажется очевидным: вся сложность в переложении специфики бизнеса на программые конструкции заключается именно в том, что конструкции кода так и остаются кодом.
AVK>Идея DSL это не отменяет.
Идея ДСЛ-я отменяет необходимость оперировать понятиями выходящими за пределы предметной области. А это может значительно упростить код. Кроме того идея ДСЛ-я еще дает в руки возможность генерировать код, а это позволяет использовать техники программирования неприемлемые при ручном кодировании.
AVK>Бизнесмен все равно не сможет сказать на языке DSL. Потому что DSL абсолютно формален, и именно формализация задачи составляет основную сложность общения с ним. DSL решает в другом месте проблему — перевод формальной спецификации в понятные компу инструкции. Бизнесмен там уже не участвует.
Тоже не совсем так. ДСЛ могут быть простыми. Такие ДСЛ-и можно давать и конечным пользователям. Не всем, но все же.
Простой пример. Многие пользователи спокойно правят конфигурационные файлы приложений. А ведь это и есть ДСЛ-и!
AVK>P.S. Пример я привел, чтобы продемонстрировать две важные вещи: AVK>1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации.
Это миф. Квалификация нужна для придумывания модели которая может описать задачу. А натянуть на нее ДСЛ уже довольно просто.
Модель же ты все равно будешь обязан создать, если задача мало-мальски большая. Так что тебе все равно делать эту работу.
AVK>2) Современные ЯОН совсем не так уж и ужасны при умелом использовании.
Совсем ужасны. Единственное, что — можно делать внутренние ДСЛ-и (средствами языка) которые немного уменьшают этот ужас. Но внешние всегда будут лучше.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Этот код никто кроме авторов понять не может.
Ну я то понял. И я, правда, не вижу ничего непонятного. Обычная бизнес-логика. Дернуть из конфигурации 1С код — будет примерно то же самое.
VD> У вас там явно есть какая-то внутренняя модель с которой вы взаимодействуете по средствами своего АПИ. Чтобы понять код нужно не только знать АПИ, но и понимать устройство модели.
Каждая сущность описывается обыкновенным .NET интерфейсом. Это все, что нужно знать для понимания кода.
VD>Лучше опиши используемую у вас модель
Вопрос непонятен
VD> и то что с ней делает этот фрагмент кода.
Ну вот как там написано, так все и есть
// откатить отработку документов в ХО
UncarryDocuments(objectsIds);
В комментарии все сказано
var cardsDeleteSet = new HashSet<IInventoryCardBase>();
Вопросы есть?
var documents = Manager.Get(objectsIds);
Получение объектов документов по их Id. Из названий методов и переменных понятно. Одно из трех обращений к инфраструктуре (оставшиеся — Manager.DeleteObjects и ((IPersistedObject)invCardObj).Master. Смысл первого очевиден, второе — получение мастера для отношения master-detail).
foreach (IInternalDisplacementDocument doc in documents)
foreach (IInventoryInternalDisplacementOperation obj in doc.GetObjects())
Цикл по каким то внутренним объектам всех документов. GetObjects это какой то прикладной метод. Можно было бы написать проще:
Вызов какого то прикладного кода, возвращающего экземпляр IInventory.
// Найти все связанные операции по видам учета
IInventoryOperation[] operations = inv.GetInventoryOperations(
null, InventoryOperationKindEnum.InternalDisplacement, (IDocument)doc, null, null, null);
Вызов прикладного кода. Суть отражена в комментарии.
foreach (IInventoryOperation operation in operations)
Цикл по найденному.
// не должно быть более поздних операцийif (inv.GetInventoryOperations(relatedOperation.AccountingKind, null, null, null, null, null)
.Any(op => op.Order > relatedOperation.Order))
throw new BusinessException("После внутреннего перемещения не должно быть операций.");
Проверка бизнес-ограничения.
if (!Equals(relatedOperation.InventoryCardBefore, relatedOperation.InventoryCardAfter)
&& !(relatedOperation.InventoryCardAfter is IAccrualAccountingInventoryCard))
cardsDeleteSet.Add(relatedOperation.InventoryCardAfter);
Опять проверка бизнес-условия и добавление в хеш, если совпало
// удалить операции
DeleteInventoryOperation(relatedOperation);
Вызов прикладного кода. Суть понятна из коментария.
И т.д. Тупой и абсолютно прозрачный код без какой либо хитрой платформенной специфики. Что тут непонятно я ХЗ.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, VladD2, Вы писали:
AVK>>А таких людей вообще — просто считанное количество. That's the problem. VD>Это вопрос образования и материалов по теме.
Это еще и вопрос нужного склада ума.
AVK>>Причем тут средства? Я не прошу тебя написать парсер и анализатор DSL, я прошу показать, как DSL будет выглядеть. VD>Дык если у человека будет средство, то он сможет найти красивое решение методом проб и ошибок (как это делается без ДСЛ-ей).
Я не спрашиваю про готовый DSL. Пусть это будет не совсем корректное решение, мне интересно именно на идею посмотреть.
VD>Ну, да. Чуда не случится и обезьяна с гранатой не станет в одночасье десантником. Но на свете много не глупых людей которые не применяют ДСЛ-и широко только потому, что нет достаточно удобного средства и нет описания как это можно сделать.
А я с этим и не спорю.
VD>Кроме того идея ДСЛ-я еще дает в руки возможность генерировать код
Это можно и без DSL делать в определенной степени.
VD>Тоже не совсем так. ДСЛ могут быть простыми. Такие ДСЛ-и можно давать и конечным пользователям. Не всем, но все же.
Ну вот мне очень хотелось бы посмотреть на то, как мог бы выглядеть DSL для бизнес логики типичной ERP системы (1С, как мы поняли, не DSL). Не нравится мой пример — можно любой другой взять, даже гипотетический. Но что то ответа нет. А именно это интересно, инструментарий для реализации уже вторичен.
VD>Простой пример. Многие пользователи спокойно правят конфигурационные файлы приложений. А ведь это и есть ДСЛ-и!
Если ьы мне был интересен DSL для конфигураций, я бы так и написал.
AVK>>P.S. Пример я привел, чтобы продемонстрировать две важные вещи: AVK>>1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации.
VD>Это миф
Ну так приводи пример, раз миф. С бизнес-спецификой ты, вроде как, в какой то степени знаком.
VD>Совсем ужасны.
Так укажи на ужасы в приведенном коде. Именно их я и хочу обсудить.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет, не знаю. Потому что почти все функции в примере — прикладные, а не системные. Системный код занимается организацией вычислений, и в приведенном отрезке его не видно. И к DSL он уж точно отношения не имеет.
Системный код это потроха ДСЛя.
WH>>Какой код и по каким моделям генерируется. WH>>У тебя есть вся информация. AVK>Эта информация для понимания кода не нужна. Совсем.
Она нужна для создания ДСЛ.
WH>>Я тоже с первого взгляда пойму, что написано на ДСЛ который сам делал. AVK>Так не DSL же, а обычный C#, в том то все и дело.
В чем дело?
Ты спроектировал систему.
Ты знаешь архитектуру.
Ты знаешь, как все выполняется.
У тебя куча информации, которую ты используешь и даже не осознаешь этого.
У меня этой информации нет.
Поэтому я не смогу ни архитектуру создать, ни ДСЛ.
AVK>Значит значит. Попробуй привести кусочек, который ты не можешь понять, и объясни что ты в нем не понимаешь.
Я постановку задачи не понимаю. Причем постановку задачи ни на этот кусок, а ну всю систему.
Без постановки задачи ДСЛ, как и архитектуру не сделать.
Да ты сам поставь себя на наше место.
Тебе дали 50 строк кода и попросили создать архитектуру.
Куда ты пошлешь с такой просьбой?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
VD>>Лучше опиши используемую у вас модель
AVK>Вопрос непонятен
Вот в этом все и дело. Если ты не понимаешь, что такое модель предметной области в приложении, но используешь ее, то и понять как натянуть ДСЛ тебе тоже будет не ясно (хотя вроде как вы это кое где сделали).
Как бы ООП придуман для того, чтобы моделировать реальность. Ваше приложение этим и занимается. Вот эти все IDocument, IInventoryOperatio, IInventoryCardBase — это интерфейс вашей модели.
AVK>... AVK>И т.д. Тупой и абсолютно прозрачный код без какой либо хитрой платформенной специфики. Что тут непонятно я ХЗ.
Да меня не интересует описание отдельных действий. Меня интересует устройство модели — что за документы, что за инвентори (это интвентаризация или инвентарь?), что за операции? Как все это друг с другом соотносится? Каковы инварианты модели?
Далее меня интересует что мы хотим сделать с моделью? Но не в виде моря вызовов неизвестного мне API, а простое человеческое описание.
Имея описание модели я смогу придумать язык для ее изменения. Причем не пимпераитвный, а высокоуровенвый — декларативный.
То что для любой модели можно придумать язык доказано наукой. Этим занимается целый раздел математики — Теория моделей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>Это вопрос образования и материалов по теме.
AVK>Это еще и вопрос нужного склада ума.
Несомненно. Кухарка не может проектировать ПО. Но тот кто может проектировать ПО, может выделять (придумывать) ДСЛ-и.
В сотый раз повторяю: главное в ДСЛ-е — модель.
Мало людей может придумать модель для задачи?
AVK>Я не спрашиваю про готовый DSL.
А я не отвечаю про готовый DSL.
AVK>Пусть это будет не совсем корректное решение, мне интересно именно на идею посмотреть.
Идею чего?
VD>>Ну, да. Чуда не случится и обезьяна с гранатой не станет в одночасье десантником. Но на свете много не глупых людей которые не применяют ДСЛ-и широко только потому, что нет достаточно удобного средства и нет описания как это можно сделать.
AVK>А я с этим и не спорю.
Дык с чем ты тогда споришь то? Мы же вроде уже выяснили, что хотя не все могут, но многие могли бы. Вот ты, например, мог бы.
VD>>Кроме того идея ДСЛ-я еще дает в руки возможность генерировать код
AVK>Это можно и без DSL делать в определенной степени.
Ну, да. На самом деле для генерации важен не DSL (язык), а модель. А модель как раз можно и без DSL-я описать и использовать. Вот только для генерации кода модель нужно иметь до рантайма. Иначе не почему будет этот самый код генерировать. А где ее взять? DSL отличный способ "загрузить" модель когда угодно (в том числе и при компиляции или развертывании). Вот и получается, что хотя сам DSL не является необходимым для генерации кода, но он все же способствует применению этой техники.
VD>>Тоже не совсем так. ДСЛ могут быть простыми. Такие ДСЛ-и можно давать и конечным пользователям. Не всем, но все же.
AVK>Ну вот мне очень хотелось бы посмотреть на то, как мог бы выглядеть DSL для бизнес логики типичной ERP системы (1С, как мы поняли, не DSL). Не нравится мой пример — можно любой другой взять, даже гипотетический. Но что то ответа нет. А именно это интересно, инструментарий для реализации уже вторичен.
Ну, предположим можно придумать DSL который бы позволил бы описать некие правила контроля конкретного документа. Что-то вроде:
Sum > 10000 => Operator mast be Supervisor
Client is PreferredPartner => UsePrice(3)
Далее помещаем эти правила в файл и позволяем пользователям изменять его. Ну, и используем эти правила при сохранении документа.
Конкретные правила для конкретны типов документов настроят сами пользователи. На это их ума точно хватит.
VD>>Простой пример. Многие пользователи спокойно правят конфигурационные файлы приложений. А ведь это и есть ДСЛ-и!
AVK>Если ьы мне был интересен DSL для конфигураций, я бы так и написал.
А нет никакой разница для чего ДСЛ. Проме того почти все ДСЛ используются для конфигурации. Скажем грамматика — это конфигурация для парсера. Описание КА — это конфигурация для машины состояний. Бизнес-правила — это конфигурация для движка проверки бизнес-правил.
AVK>Ну так приводи пример, раз миф. С бизнес-спецификой ты, вроде как, в какой то степени знаком.
Выше я привел пример гипотетических бизнес-правил. Чтобы привести аналог твоему импертивному коду мне нужно изучить вашу модель. Более того, возможно ее придется подправить для того чтобы на нее было удобно натягивать ДСЛ. Но у меня нет соменений, что если изучить модель, то в итоге получится ДСЛ который сведет приведенную тобой гору кода к нескольким строкам.
VD>>Совсем ужасны.
AVK>Так укажи на ужасы в приведенном коде. Именно их я и хочу обсудить.
Ужасы заключается в том, что в коде моного деталей реализации не относящихся к делу. Куча приведений типов. Вызовов АПИ и т.п. Я чую, что большая часть из приведенного лишняя. Но не зная модели я не могу сказать как оно должно было бы быть.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В сотый раз повторяю: главное в ДСЛ-е — модель.
Да хоть в двухсотый. Обоснования будут?
AVK>>Пусть это будет не совсем корректное решение, мне интересно именно на идею посмотреть.
VD>Идею чего?
DSL для такого домена
VD>Ну, предположим можно придумать DSL который бы позволил бы описать некие правила контроля конкретного документа. Что-то вроде: VD>
VD>Sum > 10000 => Operator mast be Supervisor
VD>Client is PreferredPartner => UsePrice(3)
VD>
VD>Далее помещаем эти правила в файл и позволяем пользователям изменять его. Ну, и используем эти правила при сохранении документа.
Ты опять скатываешься на реализацию? Как эти правила опишут логику наподобие той, что приведена в моем примере?
AVK>>Если ьы мне был интересен DSL для конфигураций, я бы так и написал.
VD>А нет никакой разница для чего ДСЛ.
Кому нет никакой разницы? Лично мне разница есть.
VD> Проме того почти все ДСЛ используются для конфигурации. Скажем грамматика — это конфигурация для парсера. Описание КА — это конфигурация для машины состояний. Бизнес-правила — это конфигурация для движка проверки бизнес-правил.
Это софистика
VD>Выше я привел пример гипотетических бизнес-правил
Совершенно непонятный. При этом куча подробностей про файлы и моменты сохранения.
VD>. Чтобы привести аналог твоему импертивному коду мне нужно изучить вашу модель.
Я до сих пор не понимаю, о чем речь.
AVK>>Так укажи на ужасы в приведенном коде. Именно их я и хочу обсудить.
VD>Ужасы заключается в том, что в коде моного деталей реализации не относящихся к делу.
Здравствуйте, WolfHound, Вы писали:
AVK>>Нет, не знаю. Потому что почти все функции в примере — прикладные, а не системные. Системный код занимается организацией вычислений, и в приведенном отрезке его не видно. И к DSL он уж точно отношения не имеет. WH>Системный код это потроха ДСЛя.
Какого DSLя? Ты о чем вообще?
AVK>>Эта информация для понимания кода не нужна. Совсем. WH>Она нужна для создания ДСЛ.
Почему? Как изменится DSL, если что то в конкретном примере системного (там ровно три точки) изменится? Давай поконкретнее.
WH>>>Я тоже с первого взгляда пойму, что написано на ДСЛ который сам делал. AVK>>Так не DSL же, а обычный C#, в том то все и дело. WH>В чем дело?
В том, что я привел пример бизнес-логики на обычном С#. Как вы утверждаете тут — код этот ужасен и трудоемок. Вот мне и интересно — как мог бы выглядеть подобный код на DSL. Без словесной шелухи и общих слов. Пока же вы дружно ищете тысячу причин, почему этого показать нельзя. Заметь, я при этом готов на любые уточнения и изменения примера, мне не этот конкретный код важен, а способ утаптывания похожей логики в DSL. И совершенно пофиг, что там в глубине спрятано за тривиальными обращениями к Manager и прочей тряхомудией по организации вычислений. Код я привел исключительно чтобы вам проще было, не с нуля сочинять.
WH>У тебя куча информации, которую ты используешь и даже не осознаешь этого.
Хватит уже общих слов ни о чем. Давай конкретно — вот эту строчку я не могу понять, потому что ... Вот тут мне надо знать, как происходит следующее ..., так как ...
WH>Поэтому я не смогу ни архитектуру создать, ни ДСЛ.
Ты же прекрасно понимаешь, что такой аргумент подойдет к любому приведенному мной примеру, что бы я не написал, не так ли?
AVK>>Значит значит. Попробуй привести кусочек, который ты не можешь понять, и объясни что ты в нем не понимаешь. WH>Я постановку задачи не понимаю.
Ага, т.е. проблема не в незнании подробностей, а в постановке задачи. Ок, нужно придумать DSL для описания бизнес-логики произвольной. Типичной для ERP системы.
WH> Причем постановку задачи ни на этот кусок, а ну всю систему.
Какую такую всю систему? У тебя DSL обязательно зависит от реализации конкретной системы? А мне всегда казалось, что DSL должны быть более менее универсально применимы в рамках D этого самого DSL. Так как ценность отраслевых языков в том и заключается, что построены они в рамках отрасли и понятны для всех, кто к отрасли имеет непосредственное отношение. А тут оказывается, что не зная досконально архитектуру конкретной реализации, даже предположить о том, как мог бы выглядеть такой DSL, нельзя. Интересно девки пляшут.
WH>Без постановки задачи ДСЛ, как и архитектуру не сделать.
Т.е. для разработки DSL обязательно нужна архитектура конкретной системы, так? Т.е., к примеру, создать SQL нельзя, не зная архитектуру конкретно MSSQL?
WH>Да ты сам поставь себя на наше место.
Я, кажется, уже писал здесь, что регулярно это делаю. И никаких архитектур мне, обычно, знать не надо. Архитектуры наоборот, приспосабливаются под DSL, потому что DSL первичен.
Вот, к примеру, вся реализация языка запросов, который я здесь приводил, находится в одной сборке, которая не ссылается ни на одну сборку платформы. Т.е. даже реализация DSL никак не учитывает какую либо специфику системы, не говоря уж о его (DSL) дизайне. И это, кстати, позволило легко применить его там, где его применять изначально не планировалось. А что было бы, если бы он оказался заточен на конкретную архитектуру?
WH>Тебе дали 50 строк кода и попросили создать архитектуру.
В 100500 раз — я не просил создавать архитектуру. То, что для демонстрации преимуществ DSL нужна полная архитектура всей системы, где он будет применяться — это твои личные теории. Моя практика эти теории не подтверждает.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, VladD2, Вы писали:
AVK>>Вопрос непонятен
VD>Вот в этом все и дело. Если ты не понимаешь, что такое модель предметной области в приложении
Я не понимаю, что нужно конкретно тебе. Не занимайся демагогией и не выворачивай мои утверждения наизнанку. Если тебе поспорить — я просто прекращу этот бессмысленный и бесполезный разговор.
VD>Как бы ООП придуман для того, чтобы моделировать реальность. Ваше приложение этим и занимается. Вот эти все IDocument, IInventoryOperatio, IInventoryCardBase — это интерфейс вашей модели.
Да без проблем могу привести. Только непонятно, чем это тебе поможет.
public interface IInternalDisplacementDocument : IDocument
{
/// <summary>
/// Вернуть дату операции
/// </summary>
/// <param name="accountingKind">Вид учета</param>
/// <returns>Дата</returns>
Date GetOperationDate(IAccountingKind accountingKind);
/// <summary>
/// Вернуть коллекцию объектов
/// </summary>
/// <returns>Коллекция объектов</returns>
IInventoryInternalDisplacementOperation[] GetObjects();
/// <summary>
/// Вернуть МОЛ получатель
/// </summary>
/// <returns>МОЛ</returns>
IMateriallyResponsiblePerson GetReceiverMateriallyResponsiblePerson();
/// <summary>
/// Вернуть МОЛ сдатчик
/// </summary>
/// <returns>МОЛ</returns>
IMateriallyResponsiblePerson GetDelivererMateriallyResponsiblePerson();
/// <summary>
/// Вернуть структурное подразделение получатель
/// </summary>
/// <returns>Структурное подразделение</returns>
IStructuralSubdivision GetReceiverSubdivision();
/// <summary>
/// Вернуть структурное подразделение сдатчик
/// </summary>
/// <returns>Структурное подразделение</returns>
IStructuralSubdivision GetDelivererSubdivision();
}
/// <summary>
/// Операция по внутреннему перемещение инвентарного объекта
/// </summary>public interface IInventoryInternalDisplacementOperation
{
/// <summary>
/// Вернуть Инвентарный объект
/// </summary>
/// <returns>Инвентарный объект</returns>
IInventory GetInventory();
}
/// <summary>
/// Операции
/// </summary>public interface IInventoryOperation
{
/// <summary>
/// Балансовая стоимость
/// </summary>
InventorySum BookValue
{get; set;}
/// <summary>
/// Вид операции
/// </summary>
InventoryOperationKind OperationKind
{get; set;}
/// <summary>
/// Дата операции
/// </summary>
Parus.Business.Date Date
{get; set;}
/// <summary>
/// Начисленная амортизация
/// </summary>
InventorySum AddedAmortisation
{get; set;}
/// <summary>
/// Остаточная стоимость
/// </summary>
InventorySum ResidualValue
{get; set;}
/// <summary>
/// Порядковый номер операции
/// </summary>
Parus.Business.Order Order
{get; set;}
/// <summary>
/// Срок полезного использования
/// </summary>
UsefulLife UsefullLife
{get; set;}
/// <summary>
/// Вид учета
/// </summary>
Parus.Business.Accounting.Core.IAccountingKind AccountingKind
{get; set;}
/// <summary>
/// Документ
/// </summary>
Parus.Business.IDocument Document
{get; set;}
/// <summary>
/// МОЛ до изменения
/// </summary>
Parus.Business.IMateriallyResponsiblePerson OriginalMateriallyResponsiblePerson
{get; set;}
/// <summary>
/// Объект в документе, который соответствует операции над инвентарным объектом
/// </summary>object DocumentObject
{get; set;}
/// <summary>
/// Ссылка на актуальное состояние объекта после операции
/// </summary>
IInventory ActualObject
{get; set;}
/// <summary>
/// Структурное подразделение до изменения
/// </summary>
Parus.Business.IStructuralSubdivision OriginalStructuralSubdivision
{get; set;}
/// <summary>
/// Местоположение инвентарного объекта
/// </summary>
IInventoryLocation Location
{get; set;}
/// <summary>
/// Начальное состояние инвентарного объекта
/// </summary>
IInventory InitialObject
{get; set;}
/// <summary>
/// Операция-основание
/// </summary>
IInventoryOperation BaseOperation
{get; set;}
/// <summary>
/// Карточка до операции
/// </summary>
IInventoryCardBase InventoryCardBefore
{get; set;}
/// <summary>
/// Карточка после операции
/// </summary>
IInventoryCardBase InventoryCardAfter
{get; set;}
}
/// <summary>
/// Инвентарный объект
/// </summary>public interface IInventory
{
/// <summary>
/// Атрибуты инвентарного объекта по видам учета
/// </summary>
IInventoryAttributesDetailCollection Attributes
{get;}
/// <summary>
/// Комплект
/// </summary>
IInventorySetDetailCollection Set
{get;}
/// <summary>
/// Возвращает операции над ИО
/// </summary>
/// <param name="accountingKind">Вид учета. Если null, то не учитывается.</param>
/// <param name="operationKind">Вид операции над ИО. Если null, то не учитывается.</param>
/// <param name="document">Документ. Если null, то не учитывается.</param>
/// <param name="startPeriod">Начало периода. Если null, то не учитывается.</param>
/// <param name="endPeriod">Окончание периода. Если null, то не учитывается.</param>
/// <param name="baseOperation">Операция-основание. Если null, то не учитывается.</param>
Parus.Business.InventoryAccounting.IInventoryOperation[] GetInventoryOperations(Parus.Business.Accounting.Core.IAccountingKind accountingKind, Parus.Business.InventoryAccounting.InventoryOperationKind operationKind, Parus.Business.IDocument document, Parus.Business.Date startPeriod, Parus.Business.Date endPeriod, Parus.Business.InventoryAccounting.IInventoryOperation baseOperation);
/// <summary>
/// Возвращает дату принятия к учету
/// </summary>
Parus.Business.Date GetAdoptionToAccountingDate();
/// <summary>
/// Возвращает карточку, в которую включен ИО
/// </summary>
Parus.Business.InventoryAccounting.IInventoryCardBase GetInventoryCard();
/// <summary>
/// Скопировать поля ИО источника в текущий ИО
/// </summary>
/// <param name="source">Инвентарный объект - источник</param>
/// <param name="sourceAttr">Инвентарный объект - источник атрибутов</param> void Copy(Parus.Business.InventoryAccounting.IInventory source, Parus.Business.InventoryAccounting.IInventory sourceAttr);
/// <summary>
/// Создать атрибуты по виду учета
/// </summary>
/// <param name="accountingKind">Вид учета. Не может быть null.</param>
Parus.Business.InventoryAccounting.IInventoryAttributes CreateAttributes(Parus.Business.Accounting.Core.IAccountingKind accountingKind);
/// <summary>
/// Установить новый автогенеренный инвентарный номер
/// </summary>void SetNewNumber();
/// <summary>
/// Возвращает ИО в карточке (объект-спецификацию)
/// </summary>
Parus.Business.InventoryAccounting.IInventoryCardObject GetInventoryCardObject();
/// <summary>
/// Получить объект обеспечения уникальности для инвентарного объекта
/// </summary>
Parus.Business.InventoryAccounting.IInventoryUnique GetInventoryUnique();
/// <summary>
/// Получить фактический срок эксплуатации на дату
/// </summary>
/// <param name="date">Дата</param>
Parus.Business.Counter GetActualUsefulLife(Parus.Business.Date date);
/// <summary>
/// Проверка соответствия учетной политике
/// </summary>
/// <param name="date">Дата</param>
/// <param name="cardType">Тип карточки</param> string CheckPolicy(Parus.Business.Date date, Parus.Business.ClassRefDomain cardType);
/// <summary>
/// Установить новый автогенеренный инвентарный номер
/// </summary>void SetNewNumber2(string lastNumber);
#region Physical Attributes
/// <summary>
/// Дата выпуска
/// </summary>
Parus.Business.Date ReleaseDate
{get; set;}
/// <summary>
/// Дата государственной регистрации
/// </summary>
Parus.Business.Date StateRegistrationDate
{get; set;}
/// <summary>
/// Дополнительный идентификатор инвентарного объекта без инвентарного номера
/// </summary>
Parus.Business.DomainGuid AdditionalId
{get; set;}
/// <summary>
/// Заводской номер
/// </summary>
SerialNumber SerialNumber
{get; set;}
/// <summary>
/// Изготовитель
/// </summary>
Vendor Vendor
{get; set;}
/// <summary>
/// Инвентарный номер
/// </summary>
InventoryNumber InventoryNumber
{get; set;}
/// <summary>
/// Количество
/// </summary>
InventoryQuantity Quantity
{get; set;}
/// <summary>
/// Модель, марка
/// </summary>
InventoryBrand Brand
{get; set;}
/// <summary>
/// Номер паспорта
/// </summary>
InventoryPassportNumber PassportNumber
{get; set;}
/// <summary>
/// Ограничения распоряжением с активами
/// </summary>
AssetsManagementRestrictions ManagementLimitations
{get; set;}
/// <summary>
/// Префикс
/// </summary>
InventoryNumberPrefix Prefix
{get; set;}
/// <summary>
/// Примечание
/// </summary>
Parus.Business.Note Note
{get; set;}
/// <summary>
/// Регистрационный номер
/// </summary>
RegistrationNumber RegistrationNumber
{get; set;}
/// <summary>
/// Факт государственной регистрации
/// </summary>
StateRegistrationFact StateRegistration
{get; set;}
/// <summary>
/// Этикетка (дата)
/// </summary>
Parus.Business.Date LabelDate
{get; set;}
/// <summary>
/// Этикетка (штрих-код)
/// </summary>
BarCode LabelBarCode
{get; set;}
/// <summary>
/// Амортизационная группа-подгруппа
/// </summary>
IDepreciationGroup DepreciationGroup
{get; set;}
/// <summary>
/// Вид НФА
/// </summary>
IInventoryObjectGroup Group
{get; set;}
/// <summary>
/// История изменений
/// </summary>
IInventory ChangesHistory
{get; set;}
/// <summary>
/// Код ОКОФ
/// </summary>
IOkof Okof
{get; set;}
/// <summary>
/// МОЛ
/// </summary>
Parus.Business.IMateriallyResponsiblePerson MateriallyResponsiblePerson
{get; set;}
/// <summary>
/// Номенклатура
/// </summary>
INomenclator Nomenclature
{get; set;}
/// <summary>
/// Организация
/// </summary>
Parus.Business.IServedOrganization Organization
{get; set;}
/// <summary>
/// Структурное подразделение
/// </summary>
Parus.Business.IStructuralSubdivision StructuralSubdivision
{get; set;}
/// <summary>
/// Регистрирующий орган
/// </summary>
Parus.Business.IJuridicalPerson RegistrationAgency
{get; set;}
/// <summary>
/// Местоположение инвентарного объекта
/// </summary>
IInventoryLocation Location
{get; set;}
/// <summary>
/// Начальное состояние инвентарного объекта
/// </summary>
IInventory InitialState
{get; set;}
/// <summary>
/// Сквозная аналитика
/// </summary>
Parus.Business.IThroughAnalytics ThroughAnalytics
{get; set;}
/// <summary>
/// Ссылка на каталог
/// </summary>
Parus.Net.Server.ISystemCatalog Catalog
{get; set;}
/// <summary>
/// Имя ИО (из номенклатуры)
/// </summary>
Parus.Business.Name Name
{get;}
/// <summary>
/// Дата принятия к учету по бух. виду учета
/// </summary>
Parus.Business.Date AdoptionToAccountingDate
{get;}
/// <summary>
/// Строковое представление ИО
/// </summary>
Parus.Business.Text InventoryString
{get;}
/// <summary>
/// Отображаемое имя
/// </summary>
Parus.Business.Text DisplayName
{get;}
}
/// <summary>
/// Объект ОС
/// </summary>public interface IInventoryCardObject
{
/// <summary>
/// Порядковый номер
/// </summary>
Parus.Business.Order Order
{get; set;}
/// <summary>
/// Инвентарный объект
/// </summary>
IInventory Inventory
{get; set;}
}
/// <summary>
/// Сервис для работы со связями между объектами.
/// </summary>public interface ILinkManager
{
/// <summary>
/// Создать связь между объектами.
/// </summary>
/// <param name="source">Персистентный объект - источник связи.</param>
/// <param name="target">Персистентный объект - приемник связи.</param>
/// <param name="role">Роль связи.</param>
/// <param name="data">Персистентный объект - данные связи.</param>void Link(IPersistedObject source, IPersistedObject target, Guid role, IPersistedObject data);
/// <summary>
/// Разорвать связь между объектами.
/// </summary>
/// <param name="source">Персистентный объект - источник связи.</param>
/// <param name="target">Персистентный объект - приемник связи.</param>
/// <param name="role">Роль связи.</param>void UnLink(IPersistedObject source, IPersistedObject target, Guid role);
/// <summary>
/// Получить все исходящие связи для данного объекта
/// </summary>
IObjectLink[] GetAllInLinks(IObjectIdentity obj);
/// <summary>
/// Получить все входящие связи для данного объекта
/// </summary>
IObjectLink[] GetAllOutLinks(IObjectIdentity obj);
/// <summary>
/// Существует ли связь с указанной ролью между объектами?
/// </summary>
/// <param name="source">Персистентный объект - источник связи.</param>
/// <param name="target">Персистентный объект - приемник связи.</param>
/// <param name="role">Роль связи.</param>
/// <returns><c>true</c>, если связь имеется, иначе <c>false</c>.</returns>bool IsLinkExists(IPersistedObject source, IPersistedObject target, Guid role);
/// <summary>
/// Метод возвращает связь, если объекты связаны связью с указанной ролью,
/// либо <b>null</b>, если такой связи нет.
/// </summary>
/// <param name="source">Персистентный объект - источник связи.</param>
/// <param name="target">Персистентный объект - приемник связи.</param>
/// <param name="role">Роль связи.</param>
IObjectLink GetLink(IPersistedObject source, IPersistedObject target, Guid role);
/// <summary>
/// Получить прикрепленные к связи данные.
/// </summary>
/// <param name="source">Персистентный объект - источник связи.</param>
/// <param name="target">Персистентный объект - приемник связи.</param>
/// <param name="role">Роль связи.</param>
/// <returns>Персистентный объект с данными, если связь имеется, иначе <b>null</b>.</returns>
IPersistedObject GetLinkData(IPersistedObject source, IPersistedObject target, Guid role);
/// <summary>
/// Проверяет есть ли связи <paramref name="role"/> от объекта <paramref name="source"/>.
/// </summary>
/// <param name="source">Источник</param>
/// <param name="role">Роль</param>
/// <returns><c>true</c>, если связь имеется, иначе <c>false</c>.</returns>bool SourceHasLinks(IPersistedObject source, Guid role);
/// <summary>
/// Проверяет есть ли связи <paramref name="role"/> к объекту <paramref name="target"/>.
/// </summary>
/// <param name="target">Цель связи</param>
/// <param name="role">Роль</param>
/// <returns><c>true</c>, если связь имеется, иначе <c>false</c>.</returns>bool TargetHasLinks(IPersistedObject target, Guid role);
/// <summary>
/// Возвращает список связей <paramref name="role"/> от объекта <paramref name="source"/>.
/// </summary>
/// <param name="source">Источник</param>
/// <param name="role">Роль</param>
/// <returns>Список связей, либо пустой список, если связей нет.</returns>
IEnumerable<IObjectLink> GetLinksFromSource(IPersistedObject source, Guid role);
/// <summary>
/// Возвращает список связей <paramref name="role"/> к объекту <paramref name="target"/>.
/// </summary>
/// <param name="target">Цель связи</param>
/// <param name="role">Роль</param>
/// <returns>Список связей, либо пустой список, если связей нет.</returns>
IEnumerable<IObjectLink> GetLinksToTarget(IPersistedObject target, Guid role);
/// <summary>
/// Возвращает список ролей связей, которые идут от объекта <paramref name="source"/>.
/// </summary>
/// <param name="source">Источник связи</param>
/// <returns>Массив ролей/пустой массив</returns>
IEnumerable<Guid> GetSourceRoles(IPersistedObject source);
/// <summary>
/// Возвращает список ролей связей, которые идут к объекту <paramref name="target"/>.
/// </summary>
/// <param name="target">Цель связи</param>
/// <returns>Массив ролей/пустой массив</returns>
IEnumerable<Guid> GetTargetRoles(IPersistedObject target);
/// <summary>
/// Получить source-объект по связи
/// </summary>
/// <param name="target">Цель связи</param>
/// <param name="role">Роль</param>
/// <returns>Объект</returns>
IEnumerable<IPersistedObject> GetSources(IPersistedObject target, Guid role);
/// <summary>
/// Получить target-объект по связи
/// </summary>
/// <param name="source">Источник связи</param>
/// <param name="role">Роль</param>
/// <returns>Объект</returns>
IEnumerable<IPersistedObject> GetTargets(IPersistedObject source, Guid role);
}
Полегчало? Или тебе еще все справочники по зависимостям нужны, чтобы окончательно в подробностях утонуть?
VD>То что для любой модели можно придумать язык доказано наукой.
Только вопрос не в этом.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
VD>>Этот код никто кроме авторов понять не может.
AVK>Ну я то понял.
А ты найди на этом форуме еще одного человека который бы понял этот код, но не работал бы в Парусе.
Я погядел вокруг, но ты уже 3 или более человекам повторил как мантру "я понял". Мы рады за тебя. Ты понял потому что знаешь детали. Именно эти детали и описывают модель.
Ты бы описал бы, что делает этот код. А то я в этой лапше имею слишком много вопросов, чтобы понять ее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>В сотый раз повторяю: главное в ДСЛ-е — модель.
AVK>Да хоть в двухсотый. Обоснования будут?
Язык — это синтаксис. Интерпретация языка (синтаксиса) есть семантика. Семантика в программах обычно выражается в виде модели.
Например, модель парсера Н2 описана вот здесь. Она состоит из ряда подмоделей. Например, модель правила грамматики описана здесь.
Язык описывающий парсер всего лишь наполняет модель конкретным содержимым (описанием языка).
По сему чтобы придумать новую конструкцию языка нужно сначала придумать ее описание в моделе.
У языка может быть разный синтаксис. Но если мы хотим иметь некоторую семантику, то мы будем вынуждены описать соответствющую модель.
Ты, проектируя, ОО-программу точно так же придумываешь модель. Но вместо того чтобы ввести язык который позволил бы просто и очевидно наполнять эту модель, ты придумываешь АПИ манипуляции моделью и забиваешь свой проект говнокодом который через это АПИ взаимодействует с моделью.
AVK>>>Пусть это будет не совсем корректное решение, мне интересно именно на идею посмотреть.
VD>>Идею чего?
AVK>DSL для такого домена
Ты еще не понял, что только ты видишь в приведенном тобой куске использования вашего АПИ — домен. Никто кто видел твой код так и не смог понять что же он реально делает. Понятно что возится с какими-то документами, инвентарными карточками и прочей мурой, но как они друг с другом связаны, как представлены в программе, и какие там взаимосвязи никто понять не может.
AVK>Ты опять скатываешься на реализацию? Как эти правила опишут логику наподобие той, что приведена в моем примере?
Ты просил пример "возможно выдуманный". Я тебе дал выдуманный пример. К логике приведенной в твоем примере мой пример не имеет никакого отношения. Понять логику твоего примера я не в силах. А ты явно не намерен ее объяснять. Вместо описания модели ты мне тут выкатил какие-то странные описания отдельных действий. Причем даже эти описания мало чего объясняют.
AVK>Кому нет никакой разницы? Лично мне разница есть.
Лично ты просто не понимаешь природу ДСЛ-ей. Что забавно ты сам их делал, но природу так и не понял.
VD>> Проме того почти все ДСЛ используются для конфигурации. Скажем грамматика — это конфигурация для парсера. Описание КА — это конфигурация для машины состояний. Бизнес-правила — это конфигурация для движка проверки бизнес-правил.
AVK>Это софистика
Это правда. ДСЛ не что иное как средство конфигурирования модели. А это и есть конфиги, по большому счету.
VD>>Выше я привел пример гипотетических бизнес-правил
AVK>Совершенно непонятный. При этом куча подробностей про файлы и моменты сохранения.
А давай спросим всех тех кто не понял твоего кода, понятен ли им мой ДСЛ? Уверен, что мой ДСЛ поймут куда больше людей чем твой "понятный" тебе код.
Даже если код не ясен, мне не составит труда объяснить семантику. А вот объяснить семантику привденной тобой лапши будет невозможно без описания всех используемых типов (модели).
VD>>. Чтобы привести аналог твоему импертивному коду мне нужно изучить вашу модель.
AVK>Я до сих пор не понимаю, о чем речь.
О ОО-модели твоего приложения, без которой нельзя понять происходящего в твоем коде.
Право не могу поверить, что реально не понимаешь что от тебя хотят.
Никому не нужно описание этого кода. Оно станет очевидным после того, как будет описана модель которой он манипулирует. А без этого объяснение отдельных операторов ничего не даст.
VD>>Ужасы заключается в том, что в коде моного деталей реализации не относящихся к делу.
AVK>Каких именно? Конкретно.
Например, вот эти строки:
UncarryDocuments(objectsIds);
var cardsDeleteSet = new HashSet<IInventoryCardBase>();
var documents = Manager.Get(objectsIds);
не имеют никакого отношения к решаемой задачи. Это чисты болерплэйт. Вызван он тем, что описание ведется не на подходщем для этого языке, а на универсальном зыке с использованием АПИ. Ну, и такого кода в этом примере большая часть.
VD>> Куча приведений типов. Вызовов АПИ и т.п.
AVK>Нет там никакой кучи.
Там ужасная лапша. И только ты, привыкший к ней, не можешь (не хочешь) этого заметить. А ведь тебе уже человека 4 сказали это.
VD>> Я чую, что большая часть из приведенного лишняя.
AVK>Кроме твоего чутья — есть что нибудь, что можно обсуждать?
Конечно! Опиши модель на базе которой построена эта лапша и я обязательно постараюсь написать код достаточный для решения проблемы.
Но, ты меня уж извини. Отвечать еще на одно сообщения в стиле "да там все ОК... да там все очевидно..." я не буду. Если тебе интересен ответ, то потрудись описать все объекты участвующие в коде, все связи между ними, и опиши почему все именно так.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Да без проблем могу привести. Только непонятно, чем это тебе поможет...
Это уже лучше. Только это все еще очень поверхностное описание интерефейса модели. А нужна конкретика. Опиши зачем нужны эти сущности. Каковы между ними связи...
Ну, и в двух словах опиши что же делала та замечательная простыня кода. Ведь она явно делала что-то не сложное. Да? Там что-то откуда-то удалялось. Вот и объясни: что, откуда, зачем и по каким правилам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>DSL для такого домена
VD>Ты еще не понял, что только ты видишь в приведенном тобой куске использования вашего АПИ — домен.
Возьми другой кусок.
VD> Никто кто видел твой код так и не смог понять что же он реально делает. Понятно что возится с какими-то документами, инвентарными карточками и прочей мурой, но как они друг с другом связаны, как представлены в программе, и какие там взаимосвязи никто понять не может
Это не имеет значения с точки зрения проектирования DSL. Потому что все, что ты перечислил, на момент создания DSL неизвестно. Все эти документы тоже определяются пользователем.
VD>Ты просил пример "возможно выдуманный". Я тебе дал выдуманный пример.
Где он?
AVK>>Кому нет никакой разницы? Лично мне разница есть.
VD>Лично ты просто не понимаешь природу ДСЛ-ей.
О, началось. Собственно, все разговоры с тобой так и заканчиваются.
VD>>>. Чтобы привести аналог твоему импертивному коду мне нужно изучить вашу модель. AVK>>Я до сих пор не понимаю, о чем речь.
VD>О ОО-модели твоего приложения
Она задается пользователем и не может учитываться в DSL.
AVK>>Каких именно? Конкретно.
VD>Например, вот эти строки: VD>
VD>не имеют никакого отношения к решаемой задачи. Это чисты болерплэйт.
Первая строка — нет. Это бизнес-операция.
VD> Вызван он тем, что описание ведется не на подходщем для этого языке, а на универсальном зыке с использованием АПИ.
Как это могло бы выглядеть на подходящем языке?
VD> Ну, и такого кода в этом примере большая часть.
Но привести ты смог только один момент?
VD>>> Куча приведений типов. Вызовов АПИ и т.п.
AVK>>Нет там никакой кучи.
VD>Там ужасная лапша.
Это все опять ни о чем.
VD> И только ты, привыкший к ней, не можешь (не хочешь) этого заметить.
Я к ней не привыкший.
VD> А ведь тебе уже человека 4 сказали это.
А чего не 8?
AVK>>Кроме твоего чутья — есть что нибудь, что можно обсуждать?
VD>Конечно!
Где оно?
VD> Опиши модель на базе которой построена эта лапша и я обязательно постараюсь написать код достаточный для решения проблемы.
Я тебе уже сказал, что модель определяется прикладником и не может напрямую учитываться в DSL.
VD>Но, ты меня уж извини. Отвечать еще на одно сообщения в стиле "да там все ОК... да там все очевидно..." я не буду. Если тебе интересен ответ, то потрудись описать все объекты участвующие в коде, все связи между ними, и опиши почему все именно так.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Потому что обсуждение терминов почти всегда оно и есть. Правда, стоит заметить, что, почему то, топики с участием netch80 явно чаще среднего по больнице на обсуждение терминов скатываются.
