Ответ на »сообщение 3125« (Илья Ермаков)
___________________________
Я уже неоднократно убеждался в спорах, что народ, который сам не пробует, так до конца и "не просекает" идеи динамической модульности... "А это зачем?"
Пока не покажешь наглядно, чтоб глаза на лоб полезли, так и будут спорить...

Ответ на »сообщение 3123« (Geniepro)
___________________________

Ответ на »сообщение 3115« (Илья Ермаков)
А в Блекбоксе такое возможно без правки кода? Без программного установления связей между переменными или виджетами посредством переменных?
Само собой - в том и смысл.
Связи строятся динамически, без перекомпиляции, с использованием метапрограммирования.
О чем я и часто говорю - ББ по гибкости эквивалентен интерпретатору, будучи полным компилятором.

Ответ на »сообщение 3122« (Антон Григорьев)
___________________________
Значит ли это, что теперь пора сделать следующий шаг и разработать новый язык - преемник Оберона, в котором будет запрещён небезопасный экспорт неабстрактных типов? Чтобы компилятор требовал сокрытия реализации внутри модуля? Ведь тогда пропагандируемый вами подход из "грамотного проектирования" превратится в обязательное требование языка.
Хе :-)
По крайней мере, супервызовы (вызов к одноименному методу типа-предка) в описании языка Component Pascal помечены как устаревшие. Однако это немного другое - в ББ пропагандируется следующий стиль расширения методов (буде таковое применяется, а для нескольких "каркасных" классов оно применяется, что вполне разумно): забиваем метод и запрещаем его дальнейшее переопределение, вместо этого вводим слот-пустышку ИмяМетода2, который можно переопределять в потомках. Метод ИмяМетода выполняет свою работу и вызывает в нужный момент ИмяМетода2. Т.е. за передачу управления в перегруженных методах полностью отвечает базовый тип, что есть верно. Программист типа-расширения не имеет возможности забыть вызвать базовый метод или вызвать его не в тот момент...

А по поводу исключения наследования реализации из языка - это слишком радикальная мера. Для базовых классов Frameworkов это наследование очень полезно.

Ответ на »сообщение 3115« (Илья Ермаков)
___________________________

У меня есть набор фокусов, которые я показываю обычно новичкам.
Даже самые простые вещи дельфистов приводят обычно в замешательство. Возможность прицепить поле ввода прямо к переменной - и то, что в то же мгновение связь установится и покажется значение. Изменили экспорт переменной на "только для чтения" - и поле тут же становится недоступным для редактирования. Автоматическое отсечение ввода по типу переменной, никаких специальных усилий для этого...

Любопытно. Это типа как лисповская библиотека Cell, которую расхваливает Jack Of Shadows.
Правда, Cell позволяетс устанавливать связи не только между визуальными компонентами и переменными, но и между разными переменными или между разными виджетами, как я понял...

А в Блекбоксе такое возможно без правки кода? Без программного установления связей между переменными или виджетами посредством переменных?

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

Ответ на »сообщение 3120« (Руслан Богатырев)
___________________________
в точку сказано!
со всем согласен

Ответ на »сообщение 3115« (Илья Ермаков)
___________________________

Да вот Вы не первый...
http://forum.oberoncore.ru/viewtopic.php?t=374 - вон сколько копий переломано...
У кого есть время и желание, пущай делают... Никаких принципиальных загвоздок там нет, за единым вопросом - ну а на фига козе баян?

Однако... Сколько энергии и желания в обсуждении, особенно со стороны энтузиастов новой волны. А баян козе точно не сильно нужен.

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

Если взять приведенное в обсуждении по ссылке деление на профессионалов-программистов, непрофессионалов-программистов и преподавателей, то пожелания-требования для пары "development-execution" в каждой из этих категорий будут, мягко говоря, слегка отличаться.

Какой можно сделать вывод? Не стоит BlackBox превращать в цветущий, пахнущий и играющий всеми цветами радуги IDE с привычным массовому потребителю стилем работы. Надо наоборот, четче отрисовать границу, отличия (принципиальные) от привычных. Кластеры-модули, а не классы! Усилия лучше направлять на развитие фундаментальных плюсов, а не на нейтрализацию внешних минусов. Подъездные пути, "последнюю милю" для мотивации изучения-освоения, конечно, стоит подправить, над этим отдельно поработать. Но не ценой потери лица BlackBox.

Заслуживает внимания звучавшая мысль насчет возрождения единой библиотеки (BB-XDS-GPCP), которая по моей вине надолго заглохла (уж извините, были на то причины, да и сейчас еще остаются). Но согласен с тем, что ее строить и затачивать надо под реальный проект, в котором она будет сильно востребована, иначе без давления потребителей рискует остаться просто благими пожеланиями для будущих поколений.

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

Ответ на »сообщение 3118« (Руслан Богатырев)
___________________________
>>>Ну да, а потом при изменении условий рушить все до основания и строить еще один новый язык.
Строить да, а рушить зачем?
Если разработаны ряды узлов и деталей для производства тракторов , а требуется построить вертолет, то придется начинать практически с нуля. А как иначе?
Из конструктора лего можно строить и трактора и вертолеты, но во первых долго, во вторых плохие :)

Ответ на »сообщение 3117« (Сергей Перовский)
___________________________

Мы опять упираемся в различные подходы к организации программирования, не имеющие отношения к языку и даже парадигме программирования.

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

Я не верю в систему, не имеющую Генерального конструктора.
Система базовых классов представляет собой мощный высокоуровневый язык описания систем определенного типа. На вопрос, что будет, если проектируемая система окажется другого типа есть единственный ответ: придется строить другой язык.

Ну да, а потом при изменении условий рушить все до основания и строить еще один новый язык.

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

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

Ответ на »сообщение 3113« (Илья Ермаков)
___________________________
>>>Не нужно делать "жирные" классы, наооборот - делить ответственность между небольшими классами.
Так все и делают в меру способностей :)
Посмотрите к примеру компоненты Дельфи для работы с БД.
Это никак не противоречит идее, что некоторое действие, которое должны уметь выполнять различные объекты, должно быть запрограммировано и ОТЛАЖЕНО раз и навсегда. Если каждый дурак начнет реализовывать это действие в соответствии со спецификацией и интерфейсом, то систему отладить не удастся никогда.
Мы опять упираемся в различные подходы к организации программирования, не имеющие отношения к языку и даже парадигме программирования. Вы представляете себе некоторую систему, развиваемую сообществом неорганизованных (прошу прощения, слабоорганизованных) программистов. Я не верю в систему, не имеющую Генерального конструктора.
Система базовых классов представляет собой мощный высокоуровневый язык описания систем определенного типа. На вопрос, что будет, если проектируемая система окажется другого типа есть единственный ответ: придется строить другой язык.