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

VD>Это уже лучше.

Напоминаю — речь о DSL. Который не может быть завязан на конкретную приведенную модель. Потому что это как при проектировании SQL учитывать конкретные таблицы конкретного решения.

VD> Только это все еще очень поверхностное описание интерефейса модели. А нужна конкретика.

Это все, что есть в системе.

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

VD>Ты бы описал бы, что делает этот код. А то я в этой лапше имею слишком много вопросов, чтобы понять ее.

Вобщем, все понятно. Результата 0. Что и ожидалось. Одни разговоры ни о чем.

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

S>>Хорошо, раз вам неочевидно, я разжую ещё подробнее: через SQL проще управлять реляционными базами данных.
V>Я фигею моя деревня. Это вам я пытался объяснить битый час. У SQL своя ниша и он далеко не панацея при работе с базами данных.
Ну, значит так объясняли.

S>>А если хотите по делу — смотрите рядом комментарии коллеги vdimas-а. Он наглядно продемонстрировал, в какой ужос превращается SQL при попытке заменить его на C++. К слову, на чистом C всё будет ещё на порядок хуже.
V>Тоже самое может произойти и с С++ при попытке заменить его на SQL. Примеры я уже привел: реестр, файловая система и т.д.
А чего ж не привести сразу решение линейных уравнений или 3d-rendering?
Потому-то SQL и DSL, что он хорошо подходит для своего домена.

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

S>>>А если хотите по делу — смотрите рядом комментарии коллеги vdimas-а. Он наглядно продемонстрировал, в какой ужос превращается SQL при попытке заменить его на C++. К слову, на чистом C всё будет ещё на порядок хуже.
V>>Тоже самое может произойти и с С++ при попытке заменить его на SQL. Примеры я уже привел: реестр, файловая система и т.д.
S>А чего ж не привести сразу решение линейных уравнений или 3d-rendering?
Напомню:

WH>>>Ну, давай изучи АПИ для прямых обращений к физической структуре БД.
V>>А в чём проблема? MFC, ADO, DAO?
S>Боюсь, ни один из них тебе не даст возможности напрямую читать/писать странички БД и расставлять локи разных уровней. А именно это и есть прямое обращение "к физической структуре БД".
V>>А вы объясните зачем?
S>Как зачем? Чтобы выполнять задачи управления данными в БД.

Как видим реестр и файловые системы дают такие возможности и прекрасно управляют данными без SQL или DSL.

S>Потому-то SQL и DSL, что он хорошо подходит для своего домена.
Про это я и говорил.

Здравствуйте, Vain, Вы писали:
V>Напомню:
V>

WH>>>>Ну, давай изучи АПИ для прямых обращений к физической структуре БД.
V>>>А в чём проблема? MFC, ADO, DAO?
S>>Боюсь, ни один из них тебе не даст возможности напрямую читать/писать странички БД и расставлять локи разных уровней. А именно это и есть прямое обращение "к физической структуре БД".
V>>>А вы объясните зачем?
S>>Как зачем? Чтобы выполнять задачи управления данными в БД.

V>Как видим реестр и файловые системы дают такие возможности и прекрасно управляют данными без SQL или DSL.
Ничего подобного мы не видим. Вам предложили "изучить АПИ для прямых обращений к физической структуре БД".
Если вам хочется порассуждать о том, что ФС — это та же БД (которая в этом топике подразумевалась реляционной, и судя по предложенным акронимам, вам это было тоже понятно с самого начала), то это не сюда.
А если хотите по делу, то ни реестр ни файловые системы никаких "прекрасных" возможностей по управлению реляционными базами данных не дают, и не дадут.

S>>Потому-то SQL и DSL, что он хорошо подходит для своего домена.
V>Про это я и говорил.
Нет, про это у вас нет ни одного топика. Есть только про то, что DAO/ADO/MFC — это API для "обращения к физической структуре БД", и про то, что в SQL есть ещё и управление пользователями, что не менее сложно, чем C++.

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

AVK>Это не имеет значения с точки зрения проектирования DSL. Потому что все, что ты перечислил, на момент создания DSL неизвестно. Все эти документы тоже определяются пользователем.
Тебе не об этом говорят.
Тебя просят рассказать о модели, на которой основаны все эти сущности.

То, что ты сделал это всё равно что показать конкретный SQL запрос человеку, который про реляционную алгебру даже не слышал. Он ничего не поймет, пока ты ему про реляционную алгебру не расскажешь.

Вот тебя и просят рассказать про твой аналог РА, на котором основана эта бизнес логика.
И что характерно ты его сам создал.
Но рассказывать о нем не хочешь.

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

V>>Как видим реестр и файловые системы дают такие возможности и прекрасно управляют данными без SQL или DSL.
S>Ничего подобного мы не видим. Вам предложили "изучить АПИ для прямых обращений к физической структуре БД".
S>Если вам хочется порассуждать о том, что ФС — это та же БД (которая в этом топике [b]подразумевалась реляционной[b], и судя по предложенным акронимам, вам это было тоже понятно с самого начала), то это не сюда.
Ничего такого здесь не подразумевалось. Речь шла про SQL как про DSL который можно сунуть везде и это прокатит.

S>А если хотите по делу, то ни реестр ни файловые системы никаких "прекрасных" возможностей по управлению реляционными базами данных не дают, и не дадут.
Я и говорил что базы сильно разные бывают, чтобы DSL ко всем им подошёл.

S>>>Потому-то SQL и DSL, что он хорошо подходит для своего домена.
V>>Про это я и говорил.
S>Нет, про это у вас нет ни одного топика.
Я не только вам отвечал.

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

WH>Тебя просят рассказать о модели, на которой основаны все эти сущности.

Без проблем.

/// <summary>
/// Интерфейс метаэлемента.
/// </summary>
public interface IMetaElement
{
    /// <summary>
    /// Имя.
    /// </summary>
    string Name {get; set;}

    /// <summary>
    /// Описание.
    /// </summary>
    string Description {get; set;}

    /// <summary>
    /// Идентификатор.
    /// </summary>
    Guid Id {get;}

    /// <summary>
    /// Элемент хранения, в котором находится указанный элемент.
    /// </summary>
    IStorageElement StorageElement {get;}
}

/// <summary>
/// Элемент хранения.
/// </summary>
public interface IStorageElement : IMetaElement
{
    /// <summary>
    /// Версия.
    /// </summary>
    Version Version {get; set;}

    /// <summary>
    /// Ресольвер внешних ссылок.
    /// </summary>
    IMetaResolver Resolver {get;}
}

/// <summary>
/// Домены
/// </summary>
public interface IDomain : IStorageElement
{    
    /// <summary>
    /// Тип данных
    /// </summary>
    DataType DataType {get; set;}
    
    /// <summary>
    /// Формат данных
    /// </summary>
    string Format {get; set;}
    
    /// <summary>
    /// Значение по умолчанию
    /// </summary>
    string DefaultValue {get; set;}
    
    /// <summary>
    /// Значения перечисления
    /// </summary>
    IDomainEnumValueCollection DomainEnumValues {get;}
}

/// <summary>
/// Классы
/// </summary>
public interface IClass : IStorageElement
{
    /// <summary>
    /// Базовый класс
    /// </summary>
    IClass BaseClass {get; set;}

    /// <summary>
    /// Свойство IsAbstract. (!A)
    /// </summary>
    bool IsAbstract {get; set;}

    /// <summary>
    /// Свойство IsPersistent. (!A)
    /// </summary>
    bool IsPersistent {get; set;}

    /// <summary>
    /// Время жизни серверного объекта
    /// </summary>
    LifeTimeType LifeTime {get; set;}

    /// <summary>
    /// Ссылка на каталог
    /// </summary>
    IClassRefAttribute CatalogLink {get; set;}

    /// <summary>
    /// Связь иерархии
    /// </summary>
    IClassRefAttribute HierarchyLink {get; set;}

    /// <summary>
    /// Спецификация класса
    /// </summary>
    IDetailCollection Details {get;}
    
    /// <summary>
    /// Методы
    /// </summary>
    IClassMethodCollection ClassMethods {get;}
    
    /// <summary>
    /// Атрибуты
    /// </summary>
    IClassPhysicalAttributeCollection ClassPhysicalAttributes {get;}
    
    /// <summary>
    /// Атрибуты
    /// </summary>
    IClassRefAttributeCollection ClassRefAttributes {get;}
    
    /// <summary>
    /// Вычисляемые атрибуты
    /// </summary>
    IClassCalcAttributeCollection ClassCalcAttributes {get;}
    
    /// <summary>
    /// Ограничения класса
    /// </summary>
    IClassConstraintCollection ClassConstraints {get;}
    
    /// <summary>
    /// Индекс класса
    /// </summary>
    IClassIndexCollection ClassIndexes {get;}
}

Вложенные типы и коллекции нужны?

WH>Но рассказывать о нем не хочешь.

Тебе показалось.

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

AVK>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?

Очевидно нужен SQL-inspired язык запросов. Просто прикрутить его к навигационному API не получится.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Очевидно нужен SQL-inspired язык запросов.

Такой язык уже есть. Но он для такого кода не особенно то и применим.

ANS> Просто прикрутить его к навигационному API не получится.

API можно и поменять. Только непонятно, как на SQL-подобном языке упростить приведенную логику.

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

ANS>>Я к тому, что наличие "встроенного" класса "Документы" ничем таким не отличается от класса "Документы" в Java/C#, чтобы язык со встроенным классом стал DSL.

V>Он только синтаксисом не отличается. Но реально отличается всем. Возьми для сравнения скриптовый объект JS — они все одинаково устроены. А в 1C встроенные объекты имеют уникальное устройство каждый, но для тебя эта уникальность скрыта за однообразным синтаксисом. Разве не в этом задача DSL — скрывать подробности относительно реализации предметной области?

Не согласен. Во-первых, не все JS-объекты одинаково устроены. JS массивы и DOM массивы они, вроде как, разные. В Smalltalk, тоже есть объекты предоставляемые VM — типа числа, методы и пр. Т.е. наличие слоя абстракции — это не критерий DSL-ности языка.

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


WH>>У тебя получается, что полные по Тьюрингу языки все ЯОН. Но по некоторым мутным причинам ты некоторые полные по Тьюрингу языки записываешь в ДСЛ.

AVK>Ограничения DSL заключаются не в ограничении Тьюринг-полноты, а в ограничении внешних возможностей. Например конструировании собственных типов определенного вида, использовании внешних библиотек и т.п.

Скриптовые языки, ориентированные на внедрение должны иметь такие ограничивающие механизмы. Напр. Safe Tcl. С другой стороны используя Tcl, как движок можно сбацать DSL. Но это будет DSL и с Safe Tcl и без.

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

ANS>>Очевидно нужен SQL-inspired язык запросов.

AVK>Такой язык уже есть. Но он для такого кода не особенно то и применим.

Значит плохой язык

ANS>> Просто прикрутить его к навигационному API не получится.
AVK>API можно и поменять. Только непонятно, как на SQL-подобном языке упростить приведенную логику.

В твоём примере, в один проход втиснуто много операций /бизнес-логики/. Оно понятно зачем — в навигационном API получить доступ к элементам очень дорого.
Теперь, бьём эту функцию на элементарные операции — получится десяток запросов. Эти запросы без комментариев будут однозначно понятнее этой лапши с комментариями.

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

PD>А можешь ответить на такой вопрос. На каком языке надо писать бинаризацию изображения? Дано greyscaled (8bpp) изображение, сделать черно-белое.

BitBlt это язык? JitBlt, Adobe Pixel Blender.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

AVK>>Такой язык уже есть. Но он для такого кода не особенно то и применим.

ANS>Значит плохой язык

Возможно.

ANS>>> Просто прикрутить его к навигационному API не получится.
AVK>>API можно и поменять. Только непонятно, как на SQL-подобном языке упростить приведенную логику.

ANS>В твоём примере, в один проход втиснуто много операций /бизнес-логики/.

Непонятно. А чем будет полезно много проходов?

ANS>Теперь, бьём эту функцию на элементарные операции — получится десяток запросов. Эти запросы без комментариев будут однозначно понятнее этой лапши с комментариями.

Пример привести можешь?

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

_>>Ну и как мне сделать на xaml что бы по нажатию пунка меню About открывалось окно About
AVK>Подписаться на метод вызова About

Ну это не интересно — это как раз везде так сейчас.

AVK>Что значит рядом? Это уже другое окно, и смысла в xaml увязывать межоконную логику немного. Ыпрочем, при желании можно примитивный компонентик написать, который это делает.

Я считаю интерфейс единой сущностью, которая должна быть задана цельно. Т.е. технически то оно может быть и разнесено на несколько файлов для удобства, но тогда между ними должны быть нормальные вызовы. Как в обычных языка программирования.

_>> Или что бы какой-то пункт контекстного меню был активен только если в дереве (допустим это у нас основной контрол в окне) выделен элемент?
AVK>Это без проблем.

Отлично! Т.е. видно что по тому пути, о котором я говорил, идут. Но к сожалению ещё очень далеко до полноценной реализации.

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

WH>>Тебя просят рассказать о модели, на которой основаны все эти сущности.
AVK>Без проблем.
Честно говря опять мало что понятно.

Правильно ли я понял что у тебя там получается ООБД?
У каждого объекта есть свой GUID используемый в качестве первичного ключа.
Версия. Как я понял сколько раз меняли объект. Хранятся ли предыдущие версии объекта?
У объектов как я понимаю могут быть коллекции вложенных объектов. А еще они умеют ссылаться на другие объекты.
Что это?

    /// <summary>
    /// Ссылка на каталог
    /// </summary>
    IClassRefAttribute CatalogLink {get; set;}

    /// <summary>
    /// Связь иерархии
    /// </summary>
    IClassRefAttribute HierarchyLink {get; set;}

В чем разница:

    /// Атрибуты
    /// </summary>
    IClassPhysicalAttributeCollection ClassPhysicalAttributes {get;}
    
    /// <summary>
    /// Атрибуты
    /// </summary>
    IClassRefAttributeCollection ClassRefAttributes {get;}

bool IsPersistent а что объекты бывают не persistent? Зачем?

Ну и главный вопрос: Почему ООБД? ИМХО в БД должны быть только данные, а не методы итп.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>А можешь ответить на такой вопрос. На каком языке надо писать бинаризацию изображения? Дано greyscaled (8bpp) изображение, сделать черно-белое.

ANS>BitBlt это язык? JitBlt,

Язык.

Even on x86 systems, Jitblt was not able to achieve adequate performance for
several reasons. Because COLA does not provide any compiler optimizations (e.g., constant
folding, CSE), optimization had to be done within Jitblt itself. Unfortunately, there
were several optimizations that could not be completed due to time restraints

Ничего удивительного. Jit есть Jit, даже если он JitBlt

А вот как из этого положения выходят

COLA includes a C API for creating and communicating with a COLA compiler
from external languages. This is available in the form of a static library that embeds the
entire COLA system (libjolt). The library exposes a single C function for creating a
COLA compiler object.

Adobe Pixel Blender.

Pixel Bender uses procedural syntax similar to languages such as C, Java, and ActionScript.

В общем, некая вариация на тему C/Java с измененем синтаксиса и неописанными характеристиками быстродействия и способом реализации.

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

WH>Правильно ли я понял что у тебя там получается ООБД?

ООБД слишком неопределенный термин.

WH>У каждого объекта есть свой GUID используемый в качестве первичного ключа.

Это неважно, что у него в качестве первичного ключа. Главное что он есть.

WH>Версия. Как я понял сколько раз меняли объект. Хранятся ли предыдущие версии объекта?

Нет.

WH>У объектов как я понимаю могут быть коллекции вложенных объектов. А еще они умеют ссылаться на другие объекты.

Да

WH>Что это?
WH>

WH>    /// <summary>
WH>    /// Ссылка на каталог
WH>    /// </summary>
WH>    IClassRefAttribute CatalogLink {get; set;}

WH>    /// <summary>
WH>    /// Связь иерархии
WH>    /// </summary>
WH>    IClassRefAttribute HierarchyLink {get; set;}
WH>

Неважно. В примере это не используется.

WH>В чем разница:
WH>

WH>    /// Атрибуты
WH>    /// </summary>
WH>    IClassPhysicalAttributeCollection ClassPhysicalAttributes {get;}
    
WH>    /// <summary>
WH>    /// Атрибуты
WH>    /// </summary>
WH>    IClassRefAttributeCollection ClassRefAttributes {get;}
WH>

Первые атрибуты описываются доменами и хранят непосредственно значение. ВТорые — ссылки на другие экземпляры объектов.

WH>bool IsPersistent а что объекты бывают не persistent? Зачем?

Неважно. В примере нет неперсистентных объектов.

WH>Ну и главный вопрос: Почему ООБД? ИМХО в БД должны быть только данные, а не методы итп.

А в БД никаких методов и нет.

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

WH>>Правильно ли я понял что у тебя там получается ООБД?
AVK>ООБД слишком неопределенный термин.
Ты оперируешь персистентными объектами.
А не реляционными таблицами.

WH>>У каждого объекта есть свой GUID используемый в качестве первичного ключа.
AVK>Это неважно, что у него в качестве первичного ключа. Главное что он есть.
Важно.

WH>>Версия. Как я понял сколько раз меняли объект. Хранятся ли предыдущие версии объекта?
AVK>Нет.
Что нет?
Первое? Второе? Или оба?

AVK>Неважно. В примере это не используется.
Важно. Как проектировать ДСЛ если не ясно что в системе твориться?

AVK>Первые атрибуты описываются доменами и хранят непосредственно значение. ВТорые — ссылки на другие экземпляры объектов.
Не понимаю. Зачем их разделять?

WH>>bool IsPersistent а что объекты бывают не persistent? Зачем?
AVK>Неважно. В примере нет неперсистентных объектов.
Ох.

WH>>Ну и главный вопрос: Почему ООБД? ИМХО в БД должны быть только данные, а не методы итп.
AVK>А в БД никаких методов и нет.
Ессно нет. Она же у тебя реляционная. Или как?

Честно говоря, я не понял, зачем была выбрана модель персистентных объектов?
Чем она такая хорошая?

Еще вопрос: Нужна ли распределенная работа?