Раз уж речь зашла о нашей разработке, то обращаюсь к сообществу за советом.
В языке еще не реализовано наследование.
Если с одиночным наследованием все ясно — практически во всех языках одно реализовано одинаково на основе принципа подстановки и виртуальных функциях.
А вот множественное наследование еще не устоялось.
В качестве примера: С++, C# и Java, Компонентный паскаль, Эйфель.
Про первые три все знают. В КП множественное наследие просто запрещено.
В Эйфеле интересное решение: есть механизм переименования наследуемых имен в классе-наследнике.
Механизм С++ нам не нравится понятно почему.
Механизм C# и Java — не хотим вводить отдельную конструкцию интерфейса.
Механизм Эйфеля — уж больно нестандартный.
Компонентный паскаль — радикальное решение.
Предлагаю пообсуждать, какой механизм множественного наследования мог бы быть полезен, и одновременно — прост для изучения.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, LaptevVV, Вы писали:
LVV>>Механизм C# и Java — не хотим вводить отдельную конструкцию интерфейса.
Q>Можно ввести отдельную конструкцию для другой разновидности наследования: CZ: Multiple Inheritance Without Diamonds
Спасибо! Очень интересно!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Раз уж речь зашла о нашей разработке, то обращаюсь к сообществу за советом.
Я что-то пропустил — о какой разработке речь?
Здравствуйте, LaptevVV, Вы писали:
LVV>Механизм C# и Java — не хотим вводить отдельную конструкцию интерфейса.
А зря.
Мое предложение — множественное наследование интерфейсов и отсутствие наследования реализаций. Т.е. классы вообще не наследуются. А для реюза кода придумать способ упрощения агрегации.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Мое предложение — множественное наследование интерфейсов и отсутствие наследования реализаций. Т.е. классы вообще не наследуются. А для реюза кода придумать способ упрощения агрегации.
наследование реализации — это и есть упрощение агрегации.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaptevVV, Вы писали:
LVV>>Механизм C# и Java — не хотим вводить отдельную конструкцию интерфейса.
AVK>А зря.
AVK>Мое предложение — множественное наследование интерфейсов и отсутствие наследования реализаций. Т.е. классы вообще не наследуются. А для реюза кода придумать способ упрощения агрегации.
Вот и я о том же — исследовать придется разные механизмы на уровне реализации и на уровне применения.
Про интерфейсы мы думали. Но о том, чтобы совсем от наследования классов отказаться — в голову не пришло.
Радикально как-то выглядит — во всех языках одиночное наследование классов есть и реализовано практически одинаково.
За предложение — спасибо! Поанализируем.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Предлагаю пообсуждать, какой механизм множественного наследования мог бы быть полезен, и одновременно — прост для изучения.
Наследование интерфейсов + синтаксический сахар для упрощенного делегирования.
Здравствуйте, LaptevVV, Вы писали:
LVV>Предлагаю пообсуждать, какой механизм множественного наследования мог бы быть полезен, и одновременно — прост для изучения.
А у меня встречный вопрос. Что вас денуло новый язык ваять? В Обероне найден фатальный недостаток?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, LaptevVV, Вы писали:
LVV>>Предлагаю пообсуждать, какой механизм множественного наследования мог бы быть полезен, и одновременно — прост для изучения.
VD>А у меня встречный вопрос. Что вас денуло новый язык ваять? В Обероне найден фатальный недостаток?
1. Раз уж среду делаем — так сразу все и сделать. Язык в том числе...
2. Хотелось разнообразного синтаксиса в рамках одной среды. Мы одной кнопочкой переключаем русский-английский (русский — важно для девственников-программистов), и синтаксис языка. Хочешь — обероноподобный, а хочешь — сиобразный...
3. Хотелось прояснить для себя некоторые вопросы — вот в частности с наследованием. Кроме того, пацан в процессе реализации интерпретатора наткнулся на интересную штуку: оказалось, ссылочную семантику и семантику значений можно реализовать в рамках одного язвка. И появилась возможность одной кнопочкой переключать это дело. Более того, если сделать API, то можно и в процессе интерпретации переключать эту семантику.
4. Просто интересно — пацану, в первую очередь.
5. Была мысля сделать в языке один контейнер вместо множества разных. Но пока отложили — вернемся в том году после опытной эксплуатации.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Философ, Вы писали:
Ф>>отсутствие наследования реализации в множественном наследовании?
AVK>Вообще отсутствие наследования реализации. Либо, в крайнем случае, отсутствие совмещенного в одном механизме наследования интерфейсов и реализаций.
Наследование реализации — вещь полезная, т.к. позволяет экономить усилия.
Это один из способов не копипастить.
Кстати, шаблонный метод — зло или нет?
Однажды я сначала руками написал около сотни практически не отличающихся наследников (все они определяли ровно два небольших метода, объявленных в базовом классе как абстрактные), а потом, когда надоело писать руками, написал для них генератор.
Сейчас даже не представляю, как всё это могло бы быть сделано без возможности наследовать реализацию.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, LaptevVV, Вы писали:
LVV>>Механизм C# и Java — не хотим вводить отдельную конструкцию интерфейса.
AVK>А зря.
AVK>Мое предложение — множественное наследование интерфейсов и отсутствие наследования реализаций. Т.е. классы вообще не наследуются. А для реюза кода придумать способ упрощения агрегации.
Кстати, ровно тот же подход предлагали оберонцы! Наследование интерфейсов, а вместо наследования реализации использовать композицию...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Философ, Вы писали:
Ф>Наследование реализации — вещь полезная, т.к. позволяет экономить усилия.
Наследование реализации — зло. В одном из проектов было примерно 8 уровней наследования, причем довольно часто оно применялось только за тем, что в наследуемом классе был подходящий метод. И делали такое не студенты, а вполне взрослые дядьки. В таком коде, если где-то обнаруживается бага, починить ее стоит совершенно адских усилий.
Ф>Это один из способов не копипастить.
Здравствуйте, Философ, Вы писали:
Ф>Кстати, шаблонный метод — зло или нет?
Присоединяюсь к вопросу про шаблонный метод. (Сам хотел спросить, но поленился.)
Пользуясь случаем, хочу задать вопрос по книжке Саттера—Александреску «Стандарты программирования на С++». Есть там два правила. (Свой экземпляр остался на работе, так что точных номеров не скажу.) Одно предписывает предпочитать абстрактные классы в API, другое — использовать идиому NVI. Нет ли здесь противоречия?