[pure С] Макросы как инструмент построения eDSL

[DIzer]

Оно не просто коряво. Оно концептуально неверно и ведет к граблям. Используйте фабрики.

Да фабрики хороши - одна проблема - не гарантируют создания экземпляра  ИСКЛЮЧИТЕЛЬНО по ЗАДАННЫМ правилам или я ошибаюсь?.

Почему же? Они именно для этого и есть, то есть для создания объектов по жестким заданным правилам.

Как ? я говорю про обеспечение непротиворечивого СОЗДАНИЯ экземпляра (переменной) составного типа - такой фокус могут обеспечить только конструкторы (а фабричные функции вы можете использовать для этой цели ,а можете и не  использовать).Т.е ничто вам не помешает инициализировать переменную так , как это сделал Игорь (имея при этом в загашнике прекрасную фабричную функцию).

[igor]

Не нравится сама идея создания и использования eDSL, или же реализация её посредством макросов?

Не нравится реализация eDSL посредством макросов.
Отношение к самой идеи eDSL у меня пока не однозначно.

[Comdiv]

Как ? я говорю про обеспечение непротиворечивого СОЗДАНИЯ экземпляра (переменной) составного типа - такой фокус могут обеспечить только конструкторы (а фабричные функции вы можете использовать для этой цели ,а можете и не  использовать).Т.е ничто вам не помешает инициализировать переменную так , как это сделал Игорь (имея при этом в загашнике прекрасную фабричную функцию).

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

[DIzer]

Как ? я говорю про обеспечение непротиворечивого СОЗДАНИЯ экземпляра (переменной) составного типа - такой фокус могут обеспечить только конструкторы (а фабричные функции вы можете использовать для этой цели ,а можете и не  использовать).Т.е ничто вам не помешает инициализировать переменную так , как это сделал Игорь (имея при этом в загашнике прекрасную фабричную функцию).

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

Плодить иерархию по пустякам... и потом, если нет в ЯП такого понятия как ADT (как ,например, в стандартном обероне)?

[Comdiv]

По пустякам и конструкторов не надо.

[DIzer]

По пустякам и конструкторов не надо.

Вы это к тому, что Оберон - язычек на пустячек? 

[vlad]

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

2igor: Именно это я и имел ввиду применительно к оберонам.

[Comdiv]

По пустякам и конструкторов не надо.

Вы это к тому, что Оберон - язычек на пустячек? 

В качестве шутки сойдёт, но из контекста разговора понятно, что нет.

[DIzer]

По пустякам и конструкторов не надо.

Вы это к тому, что Оберон - язычек на пустячек? 

В качестве шутки сойдёт, но из контекста разговора понятно, что нет.

Точно. Интересно, что эта тема (о необходимости  в ЯП конструкций аналогичных конструкторам) поднималась несколько раз у коровцев  (как оберонофилами так и оберонофобами).. в качестве аргументации в основном были "жизненные" примеры.. Понятно что на каждый такой пример находился контрпример (или , на худой конец, "нафиг энто нужно"). Я считаю - что даже в простом СОВРЕМЕННОМ  ЯВУ такая вещь (назовем ее инициализатором) - крайне полезна ибо позволяет описывать моделируемую систему  точно и надежно (это является для меня ДОСТАТОЧНЫМ основанием).

[igor]

Я считаю - что даже в простом СОВРЕМЕННОМ  ЯВУ такая вещь (назовем ее инициализатором) - крайне полезна ибо позволяет описывать моделируемую систему  точно и надежно (это является для меня ДОСТАТОЧНЫМ основанием).

Необходимость в конструкторах (или инициализаторах) я для себя обосновываю несколько иначе.
Основную цель конструкторов я вижу в том, чтобы перевести только что созданный объект (до первого использования) во внутренне непротиворечивое состояние. Дело в том, что конструктор - это особый метод, который вызывается тогда, когда объекта ещё как бы нет (в том смысле, что этот объект ещё не доступен для использования). К тому же этот метод вызывается автоматически, так что у программиста нет возможности "забыть" его вызвать.

Всё это звучит несколько академически, но я действительно так думаю. 

[DIzer]

Я считаю - что даже в простом СОВРЕМЕННОМ  ЯВУ такая вещь (назовем ее инициализатором) - крайне полезна ибо позволяет описывать моделируемую систему  точно и надежно (это является для меня ДОСТАТОЧНЫМ основанием).

Необходимость в конструкторах (или инициализаторах) я для себя обосновываю несколько иначе.
Основную цель конструкторов я вижу в том, чтобы перевести только что созданный объект (до первого использования) во внутренне непротиворечивое состояние. Дело в том, что конструктор - это особый метод, который вызывается тогда, когда объекта ещё как бы нет (в том смысле, что этот объект ещё не доступен для использования). К тому же этот метод вызывается автоматически, так что у программиста нет возможности "забыть" его вызвать.

Всё это звучит несколько академически, но я действительно так думаю. 

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

[DIzer]

Я считаю - что даже в простом СОВРЕМЕННОМ  ЯВУ такая вещь (назовем ее инициализатором) - крайне полезна ибо позволяет описывать моделируемую систему  точно и надежно (это является для меня ДОСТАТОЧНЫМ основанием).

Необходимость в конструкторах (или инициализаторах) я для себя обосновываю несколько иначе.
Основную цель конструкторов я вижу в том, чтобы перевести только что созданный объект (до первого использования) во внутренне непротиворечивое состояние. Дело в том, что конструктор - это особый метод, который вызывается тогда, когда объекта ещё как бы нет (в том смысле, что этот объект ещё не доступен для использования). К тому же этот метод вызывается автоматически, так что у программиста нет возможности "забыть" его вызвать. Кстати , не так давно вы пытались сделать что-то подобное по отношению к вычислениям с плавающей точкой...

Всё это звучит несколько академически, но я действительно так думаю. 

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

[igor]

Описанная вами проблема лечится просто - при создании переменной в нее заносится некоторое значение из области определения (например, численные типы инициализируются нулем, указатели -NIL) .

В том то и дело, что с точки зрения автора объекта нулевые значения могут быть некорректными. Например, в объекте Window поле width означает ширину окна, а по замыслу автора ширина любого окна (любого экземпляра объекта Window) ни при каких обстоятельствах не должна быть меньше 50 пикселей. Как гарантировать этот инвариант при создании объекта? При помощи конструктора (!), чтобы даже нечаянно не получилось создать объект, у которого будет width < 50.

[Илья Ермаков]

Плодить иерархию по пустякам...

В КП есть LIMITED RECORD, как раз для такой цели (чтобы в обход фабрики нельзя было создать).
Используется редко (но метко), потому что базовый абстрактный тип имеет смысл вводить в большинстве случаев. И уж в случае прикладного моделирования точно (чтобы потом свободно играть с разными вариантами реализации какого-нибудь понятия).

Относиться к желательности введения ABSTRACT-типа можно так же, как к обязанности объявлять секцию interface в Object Pascal, дефинишн в Модуле или Аде, или хидер в Сях. Объём работы не увеличивается, т.к. как раз дефинишн Оберон генерирует автоматом, только звёздочки успевай ставить... Это как раз и к вопросу о том, почему в Оберонах теряет актуальность явное объявление спецификаций. Основные спецификации фиксируются в объявлениях ABSTRACT-типов.

[valexey]

В КП есть LIMITED RECORD, как раз для такой цели (чтобы в обход фабрики нельзя было создать).

Но это только для переменных в куче. Не интересно.

Относиться к желательности введения ABSTRACT-типа можно так же, как к обязанности объявлять секцию interface в Object Pascal, дефинишн в Модуле или Аде, или хидер в Сях.

В сях хидер не обязателен абсолютно.

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

Где в Обероне ABSTRACT-типы? Их там как раз вроде бы нет.

Алсо беспорядочно раскиданые звездочки по тексту очень нелегко вылавливать. Я это дело прочувствовал когда на этих выходных писал на Oberon-7 :-)