OberonCore

Воот. Я ждал, когда всплывёт вопрос контрактов. Только вот мух с котлетами и правда мешать не надо
Наличие/отсутствие контракта и тип связывания совершенно независимые вещи. Контракт тоже может проверяться статически/динамически (не при каждом вызове, а в момент установления связи, например). В Zonnon, например, полная поддержка контрактов на сообщения, но допустимо как статическое, так и динамическое связывание (и проверка контракта). Решением же с методами просто поставили жирную точку на возможности хоть как-то маневрировать с типом связывания. Впрочем, это непонимание компонентности до конца у них постоянно прослеживется. В .NET было что-то не продумано с выгрузкой и динамической заменой сборок. Тянутся в верном направлении, но всё равно мыслят частично привычными категориями

Я просто пояснил, что "убогие целочисленные идентификаторы", помимо задачи расширения системы, обеспечивают конкретные свойства недоступные оберонам. Пусть и не самым естественным способом.

Гм... Что-то я вот тоже не понимаю крутизны WITH. Т.е. я не вижу в нем ничего нового. В том же C++ имеет место быть typeid() который возвращает объект класса type_info . У класса имеется operator==. Ну, собственно и всё. Можем спокойно писать:

if (typeid(MyClass1) == typeid(msg) {
// to do something
} else if (typeid(MyClass2) == typeid(msg) ) {
// to do something else
}
else {
// unknown message type
}

Это не кейс конечно, но какая разница?

Можно указатели на функции положить в map и спокойно вызывать:
messageMap[typeid(msg)]();

if (messageMap.find(typeid(msg)) == messageMap.end()) {
// unknown message type
} else {
messageMap[typeid(msg))](msg); // вызов нужной функции.
}

Естественно это может быть и не map, и туда не обязательно класть именно что указатели на функции. Там могут быть указатели на объекты, или даже пары -- <объект,указатель на функцию этого объекта>.

Вылепить можно всё что угодно.

Проверка по typeid не учитывает наследования. Остается dynamic_cast или велосипеды.

Гм. Тоесть, имеется ввиду что если пришло сообщения типа B унаследованнного от A, то typeid это никак нам не подскажет? ОК. А что если мы хотим иметь дело ТОЛЬКО с типом B и никак не с типом A? WITH это может?

Можно много чего. Вопрос в том, является ли это настолько удобным, что разработчики будут постоянно это использовать. Оберон это не просто позволяет, он это пропагандирует, при этом даже не в архитектурных, а в алгоритмических задачах, в которых передача расширяемых сообщений резко повышает понятность и выразительность, расслаивает логику по уровням. Например, при написании транслятора и работе с синт. деревом.

Кроме того, есть ещё вопрос эффективности. В реализациях Оберона работа с описателями типов специально организована так, чтобы WITH не стоил лишнего по сравнению с CASE (два разыменования, два сдвига по смещению, одно сравнение). Т.е. становится выгодно типизировать вариативные данные не идентификаторами (например, перечислений), а непосредственно языковым типом.

С++ неокмпонентный язык, тут особо сравнивать и смысла нет.
А про C#, помнится, был какой-то пример в статье на RSDN, когда манипуляция с динамическим типом объекта (не помню, какая) сжирала около 300 операций. Опять тот же синдром - нет у разработчиков чутья, что и как может быть использовано, вроде и сделали компонентность, а то одно не так, то другое... Потому что окромя С++ ничего не видели, а в качестве образца новизны Яву перед глазами имели.

То есть, если Вы напишете typeid(x) == typeid(ClassA), то это сравнение будет верным только в том случае, если x имеет точный тип ClassA, и неверным - если тип ClassAA, наследованный от ClassA.

Т.е. остаётся только, как Влад заметил:
if ( dynamic_cast<ClassA>(x) != NULL ) {
dynamic_cast<ClassA>(x)....
}
else if...

Между прочим, ещё неизвестно, какие там закидоны (и с какой эффективностью) возникнут на конкретных реализациях. Средство-то не из основных, не особо любимое и уж точно для цели таких выборок не предназначенное

Гм... А разве передача сообщений используется только в чем-то сильно компонентном? Любая программа реальных размеров (>100 тыс. строк) имеет внутри более-менее блочно-модульно-компонентную структуру. Эти блоки должны быть расширябельны и слабо связаны друг с другом. Обычно пишут программу сразу несколько человек. Причем зачастую слабо взаимодействующих. Т.о. это всё слабо отличается от того же BB. Ты написал нечто, и ты не знаешь как это нечто будет использовать другой программист. Как изменятся протоколы и т.д. и т.п.

Особенно это касается монстров аля Мозиллы -- около 2-х миллионов строк кода и больше сотни активных разработчиков.

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

Да, кроме того, потомок (в С++) может разительно отличаться от предка (в т.ч. и относительно доступности методов и полей). Поэтому я не уверен что если мы хотим класс А, то мы обязательно хотим ещё и классы АА, АБ, и АаА (где а -- другой, второй предок класса АаА).

Это очень странное желание в мире ООП.

Он может отличаться как угодно, но обязан поддерживать семантику базового класса (или не должен от него наследоваться).

Можно показать на конкретном примере эту самую жирную точку? Где связь с типом не дает расширяться системе?

Ключевые слова: должно быть и более-менее как раз и определяют самую суть проблемы... :о)))

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

Думаю, множественное наследование ставит крест на эффективности. Это, естественно, при сравнении с аналогичными возможностями в других языках, а не по сравнению с другими операциями на данном языке.

При чём тут множественное наследование?
Вернее так: как на эффективности, расширяемой а-ля Оберон системы, отражается существование в природе множественного наследования?

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

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

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

Насчет производительности WITH vs dynamic_cast и проч. -- думаю тут гадать бессмысленно. Надо просто написать тест да посмотреть что да как. Думаю для многих языков будет достаточно большой разброс в зависимости от реализации.