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

[DIzer]

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

Так вы дойдете до необходимости подсветки, однако - нехорошо товарищч... 

[DIzer]

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

Я вам ПРО ЭТО И ГОВОРЮ (что САМО ЗНАЧЕНИЕ ПЕРЕМЕННОЙ  - ОПРЕДЕЛЯЕТСЯ ВНЕШНИМИ ПО ОТНОШЕНИЮ к ЯП ФАКТОРАМИ -ЗАДАЧЕЙ (если вам так легче это осознать)) - с точки зрения  обеспечения непротиворечивости внутренней логики программы - ДОСТАТОЧНО сделать то что я сказал.

[DIzer]

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

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

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

И это Вы называете простым ЯП и проталкиваете его  для начинающих ? - мля... да и только.

[valexey]

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

Так вы дойдете до необходимости подсветки, однако - нехорошо товарищч... 

Скорее перепишу все что есть с нуля самостоятельно так, чтобы экспортируемые сущности были сгруппированы отдельно. Благо исходников на Обероне-7 кот наплакал, можно вообще все переписать безболезненно совершенно :-)

[DIzer]

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

Так вы дойдете до необходимости подсветки, однако - нехорошо товарищч... 

Скорее перепишу все что есть с нуля самостоятельно так, чтобы экспортируемые сущности были сгруппированы отдельно. Благо исходников на Обероне-7 кот наплакал, можно вообще все переписать безболезненно совершенно :-)

Вы это - злобный эгоист- индивидуалист ? как не стыдно 

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

И это Вы называете простым ЯП и проталкиваете его  для начинающих ? - мля... да и только.

А Вы считаете что ООП имеет отношение к начинающим? (утрирую)
К начинающим имеет отношение использование объектов, это проходит на ура.

Как вводить понятия ООП - вопрос вообще открытый. У меня есть хорошая безболезненная последовательность, поддержанная примерами, но только в этом году она сложилась. Дело начинается с объявления типов, расширяющих некоторые стандартные (сначала расширение Services.Action, для создания асинхронных действий; потом расширение Views.View), такие типы вообще не экспортируются. Потом в какой-то момент, имея уже графический объект (игра "Сапёр"), отделяем от вьюшки модель - и вот тут-то впервые создаём свой тип. И ABSTRACT появляется тоже естественно (тем более, что до этого мы занимались тем, что такие ABSTRACT-ы расширяли-реализовывали). Проблем не замечено.

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

ООП ещё требует осмысления и доочищения, это понятно, но на данном уровне сбалансированнее, чем в КП, пока не видать.

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

Вопли про подсветку непонятны. В Блэкбоксе экспортированные элементы выделяются жирностью, естественно. В чём проблема.
Проблема как раз у Веселовского на плоском тексте.

[igor]

САМО ЗНАЧЕНИЕ ПЕРЕМЕННОЙ  - ОПРЕДЕЛЯЕТСЯ ВНЕШНИМИ ПО ОТНОШЕНИЮ к ЯП ФАКТОРАМИ -ЗАДАЧЕЙ (если вам так легче это осознать)

Я не могу осознать другое, зачем Вы тогда предлагали инициализировать поля нулевыми значениями? Вы считаете что такое решение заранее подойдёт для всех задач? 

[DIzer]

САМО ЗНАЧЕНИЕ ПЕРЕМЕННОЙ  - ОПРЕДЕЛЯЕТСЯ ВНЕШНИМИ ПО ОТНОШЕНИЮ к ЯП ФАКТОРАМИ -ЗАДАЧЕЙ (если вам так легче это осознать)

Я не могу осознать другое, зачем Вы тогда предлагали инициализировать поля нулевыми значениями? Вы считаете что такое решение заранее подойдёт для всех задач?  

1. ЗАТЕМ, что ЭТО ЛЕЧИТ ПРОБЛЕМУ УКАЗАННУЮ В ВАШЕМ СООБЩЕНИИ (ОБЕСПЕЧИВАЕТ НЕПРОТИВОРИЧИВОСТЬ)... 2. Затем, что для большинства задач начального уровня (ИМХО)  - это разумный ( и естесственный с  точки зрения человеческой психики) выбор 3. затем что это безопасно для исполнителя и оружающей среды- разве этого мало?

[valexey]

Вопли про подсветку непонятны. В Блэкбоксе экспортированные элементы выделяются жирностью, естественно. В чём проблема.
Проблема как раз у Веселовского на плоском тексте.

А они там выделяются автоматически? Опять таки, речь шла про Оберон(1,2) таки, а не про КП и тем более не про его конкретную реализацию-ББ.

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

PS. Инструментальные среды я в данный момент не критикую. Я критикую подход который начался в Обероне и укоренился в яве и шарпе — не писать отдельно спецификацию на компонент. Спецификация должна писаться ручками, потому что она первична, а вот реализация может частично по ней генерироваться :-)

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

Если экспортируется только ABSTRACT-тип, то там всё сверху модуля.

В среде нажать Ctrl-D, чтобы увидеть спецификацию, не проблема. (А не раз говорилось, что Обероны без среды теряют очень многое).

По поводу первичности спецификации - я с Вами соглашусь, рассуждая эдак "вообще". Но в конкретно своей практике, по причине того же переноса акцента на ABTSRACT-типы и т.п., я имею подтверждение того, что спецификации на модули не востребованы. Они востребованы, безусловно, когда могло быть несколько реализаций одного модуля. Сейчас (в компонентном ООП) так не делается.

[valexey]

Если экспортируется только ABSTRACT-тип, то там всё сверху модуля.

В среде нажать Ctrl-D, чтобы увидеть спецификацию, не проблема. (А не раз говорилось, что Обероны без среды теряют очень многое).

Кстати, Оберон не один такой, java/c# тоже очень многое теряют без среды. Становятся почти что неюзабельными (особенно java). Haskell, кстати, без repl'а его тоже становится не слишком удобным (потому как не запустить в произвольный момент времени выводилку типов).

Среда по большей части не важна таким языкам как: С, C++, Ada, ObjC, Modula, D.

[DIzer]

И это Вы называете простым ЯП и проталкиваете его  для начинающих ? - мля... да и только.

А Вы считаете что ООП имеет отношение к начинающим? (утрирую)
К начинающим имеет отношение использование объектов, это проходит на ура.

Как вводить понятия ООП - вопрос вообще открытый. У меня есть хорошая безболезненная последовательность, поддержанная примерами, но только в этом году она сложилась. Дело начинается с объявления типов, расширяющих некоторые стандартные (сначала расширение Services.Action, для создания асинхронных действий; потом расширение Views.View), такие типы вообще не экспортируются. Потом в какой-то момент, имея уже графический объект (игра "Сапёр"), отделяем от вьюшки модель - и вот тут-то впервые создаём свой тип. И ABSTRACT появляется тоже естественно (тем более, что до этого мы занимались тем, что такие ABSTRACT-ы расширяли-реализовывали). Проблем не замечено.

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

ООП ещё требует осмысления и доочищения, это понятно, но на данном уровне сбалансированнее, чем в КП, пока не видать.

Какая вьюшка или фигнюшка - я говорю про простые задачи - понятные школьникам  напр. есть точка (на плоскости) из 1 координатной четверти, есть точка из 3 -найти рассояние между ними... самый надежный способ определить два типа и функцию возвращающую расстояние.- здесь нет никакого полиморфизма или наследования... работаем только с переменными пользовательских типов. И уж коль скоро мы говорим о них (пременных пользовательских типов ) - почему бы не сделать их полноценными (коль скоро постулируем СТРОГУЮ ТИПИЗАЦИЮ). Да и еще я говорил про простой СОВРЕМЕННЫЙ ЯВУ..все -таки кое какой багаж за последние 40 лет накоплен...

[DIzer]

....
Среда по большей части не важна таким языкам как: С, C++, Ada, ObjC, Modula, D.

Вы это про что (почему для Модулы это не важно а для Оберона важно)? про наличие заголовочных файлов ? так в случая Оберонов они без проблем генерируются при компиляции (если компилятор нормальный - напр. XDS)  - не фиг писать ручками то что можно сделать автоматически (впрочем можно и ручками -если есть желание) другое дело что проблему навигации
по коду это не решает  (но то же самое можно сказать и про любой ЯП из вашего списка).

[Comdiv]

Скорее перепишу все что есть с нуля самостоятельно так, чтобы экспортируемые сущности были сгруппированы отдельно. Благо исходников на Обероне-7 кот наплакал, можно вообще все переписать безболезненно совершенно :-)

Просто добавьте DEF-файлы, и в зависимости от задач и предпочтений решайте - генерируются они автоматически из модулей или наоборот - из них автоматически генерируются болванки модулей. Так что то, как сделано в Обероне - хорошо, надо только увидеть это.