Ответ на »сообщение 4410« (Святослав Ушаков)
___________________________

Ответ на »сообщение 4409« (Сергей Губанов)
___________________________

Ответ на »сообщение 4408« (Святослав Ушаков)

"повторное использование исходного текста" = "mutual exclusion". Единицей (повторного) использования являются модули, или даже целые подсистемы взаимосвязанных модулей. Про текст (или как Вы его называете - код) в модульных системах забудьте.

Нет, я не про повторное использование ТЕКСТА. Я про повторное использование СКОМПИЛИРОВАННЫХ единиц кода (процедур, методов, модулей). Повторное использование текста как раз легко и возможно (Copy/Paste - помните?), но это плохая практика. А вот скомпилированные методы/процедуры из МОДУЛЕЙ (возможно, просто плохо спроектиированных?) я использовать не могу, так как они или не экспортированы, или запрещены для наследования. Вот что меня всегда раздражало, ещё со времён изучения мной ООП на примере Turbo Vision. Но Turbo Vision по сравнению с BlackBox - просто совсем открытая система! В BlackBox есть куча готовых, ну, к примеру, контролов, но невозможно ни один из них расширить! Для программиста, бросающего контролы на форму - это нормально, но если я хочу свой контрол сделать, то - АУ! Предстоит куча повторной работы, практически с нуля. Зачем?

Для реализации наследования от классов в других модулях нужно отказаться, всего навсего, от динамической линковки :)))
Хотя тут могут всё, таки быть решения. Можно знать только интерфейс предка и использовать агрегацию вместо наследования. Так например делает Python. Паревный метод, но никто не запрещает его использовать в компиляторе, в самом ядре на низком уровне, а сверху будет обычное наследование. Таким образом в каждом объекте будет ссылка на кусочек этого объекта написаный в родительском классе. Хитро придётся обойтись с таблицей виртуальных методов. Хотя... в обероне с ней и так хитро со стороны синтаксиса.

Ответ на »сообщение 4409« (Сергей Губанов)
___________________________

Ответ на »сообщение 4408« (Святослав Ушаков)

"повторное использование исходного текста" = "mutual exclusion". Единицей (повторного) использования являются модули, или даже целые подсистемы взаимосвязанных модулей. Про текст (или как Вы его называете - код) в модульных системах забудьте.

Нет, я не про повторное использование ТЕКСТА. Я про повторное использование СКОМПИЛИРОВАННЫХ единиц кода (процедур, методов, модулей). Повторное использование текста как раз легко и возможно (Copy/Paste - помните?), но это плохая практика. А вот скомпилированные методы/процедуры из МОДУЛЕЙ (возможно, просто плохо спроектиированных?) я использовать не могу, так как они или не экспортированы, или запрещены для наследования. Вот что меня всегда раздражало, ещё со времён изучения мной ООП на примере Turbo Vision. Но Turbo Vision по сравнению с BlackBox - просто совсем открытая система! В BlackBox есть куча готовых, ну, к примеру, контролов, но невозможно ни один из них расширить! Для программиста, бросающего контролы на форму - это нормально, но если я хочу свой контрол сделать, то - АУ! Предстоит куча повторной работы, практически с нуля. Зачем?

Ответ на »сообщение 4408« (Святослав Ушаков)

Не надо так сильно расстраиваться. Проектировать модульные системы сложнее чем монолитные программы. "Модульность" & "повторное использование исходного текста" = "mutual exclusion". Единицей (повторного) использования являются модули, или даже целые подсистемы взаимосвязанных модулей. Про текст (или как Вы его называете - код) в модульных системах забудьте. Не можете - откажитесь от модульных систем вовсе, пишите по старинке - монолитные программы, их писать проще.

Сокращённая выдержка из диалога с http://blackbox.metasystems.ru/forum/
1.
P.S. Сильно жалко, что стандартный грид недоступен для расширения. Приходится делать свой. Как вы думаете это правильно? Надёжность за счёт расширяемости?

2.
Что касается расширения - в компонентных системах рекомендуется избегать межмодульного наследования реализации, т.к. это ведет к тесным зависимостям от внутренних особенностей работы конкретной версии модуля - так называемая Fragile Base Class Problem (проблема хрупкости базового класса). Рекомендуется между модулями, особенно от различных поставщиков, наследоваться только от абстрактных классов. Если нужно, можно унаследоваться от базового абстрактного класса, агрегировать поле того типа, от которого хотелось бы наследоваться, и дальше вызовы части процедур делегировать ему.
1.
Ну в общем - понятно, хотя, по идее эта проблема должна затрагивать только экземпляры классов-потомков. Разве нет? Экземпляры базового класса ведь останутся нехрупкими?
Жаль только, что из подходящих абстрактных классов имеется только Controls.Control. Был бы какой-нить абстрактный класс табличного поля, с базовой функциональностью (ну, частично абстрактный).
2.
Так и есть. Хрупкость в том смысле, что потомки опираются на нечто ненадежное, что может меняться.
Но, между прочим, это касается и разработчика базового класса. Единожды позволив наследовать реализацию, он очень себя стесняет в развитии, т.к. если много пользователей полагались на какую-нибудь недокументированную особенность, он уже не сможет свободно уйти от этой особенности.
1.
Кстати, вот опять же всплыла тема, про которую я уже говорил. Закрывая доступ к методам, и таким образом, защитившись от "хрупкости" базового класса мы сводим повторное использование кода к очень малым величинам, и переходим к китайскому методу Copy/Paste
2.
К сожалению, за надежность приходится платить. Как ни парадоксально, позволить бесконтрольно расширять систему - значит вскоре свести ее расширяемость вообще на нет, т.к. разработчик не сможет сделать ни шага в сторону без того, чтобы не вызвать проблемы у множества клиентов.
Кстати, не надо забывать и об агрегации как заменителе наследования. Во многих случаях такое решение не только приемлемо, но и единственно возможно: обернуть объект какого-либо закрытого для наследования типа в свой - потомок от того же абстрактного типа, что и обернутый, и делегировать часть вызовов обернутому объекту. Может быть, это подошло бы и в вашем случае?

А вот Copy-Paste действительно помогает. Если время не терпит, иногда беру исходный код из стандартного модуля и изменяю в нем только то, что нужно. Вообще, открытые коды ББ здорово помогают, без них разобраться и быстро начать работать было бы гораздо сложнее.
1.
Вот где-то я читал, что Copy-Paste - это любимейший китайский способ сохранения и размножения ошибок
________________________________________________________________________________
Не совсем в тему Оберона, как такового, но об идеологии проектирования иерархии классов, применяемую в BlackBox. 1 - Это я. Меня лично колбасит, когда есть класс, который меня почти во всём устраивает, и достаточно переопределить пару методов и будет то, что надо, но переопределить имено эти методы - НЕЛЬЗЯ. Тогда меня начинает колбасить в 2 раза сильнее, ибо надо ПОВТОРЯТЬ уже имеющуюся функциональность (объём кода от десяти и выше раз больше, чем надо было бы при переопределении всего 2-х методов), при этом изобретая и отлаживая то, что уже было изобретено и отлажено. Иногда проще, действительно использовать Copy/Paste. Где она, модульность - АУ! Где оно, повторное использование кода, ась? Ррррр!!!

Да, можно иногда использовать агрегирование - но я не об этих случаях.

Ответ на »сообщение 4406« (Владимир Лось)
Единственно плохо - сейчас вот тема "убежит" - вообще никто знать не будет.

Может ещё там продублировать: http://blackbox.metasystems.ru/forum/

Ответ на »сообщение 4405« (Сергей Губанов)
___________________________
Естественно. Разница есть, из дома - по модему, с работы - по выделенке...
У меня из дома скорише получается... :о)
Единственно плохо - сейчас вот тема "убежит" - вообще никто знать не будет.
Может попросить уважаемую Королеву в здешний список ссылок вставить?

Ответ на »сообщение 4396« (Владимир Лось)
Это что - выходные виноваты?

Естественно. Разница есть, из дома - по модему, с работы - по выделенке...

Ответ на »сообщение 4403« (Владимир Лось)

Тю! Не с той ноги встали? :о)
Сори. Есть немного. Позавчера как встал с левой так до сих пор сменить ногу не могу. Затекла :(

Всем: Помнится, тут месяца 3 назад на мой вопрос по поводу тестов для компилятора Оберона-2, говорили что тесты в планах разработки. Хочу спросить ещё раз. Двигается ли разработка? Имхо если взять доку, условно разбить её на правила. Правила поделить между желающими интузиастами. То в результате для одного человека не так уж много работы. Думаю человек 6 найдётся. Зато это весчь. Мне пока приходится довольсвоваться 3мя десятками своих тестов и проектом Hostess, который местами с глюками, да и тестирует с ненормальным покрытием.
Ну так вот! Давайте наделаем тестов! и все заживут счастливо.

Ответ на »сообщение 4402« (Ev_genus)
___________________________
Только там что-то не активно.
Замечено, что полностью вся функциональность не реализуется под IE. Почему - не знаю... Если работать из Мозиллы или Оперы - всё в порядке...
Логины собираете?
В смысле?
Могу навести на сайтик с десяток флудеров, офтоперов и флеймеров.
Тю! Не с той ноги встали? :о)

Для количества и я подпишусь. Только там что-то не активно. Логины собираете? Могу навести на сайтик с десяток флудеров, офтоперов и флеймеров.