Планирует ли MS в новой версии .NET добавить в C# поддержку шаблонов и множественного наследования классов?
Или, может, в будущем они планируют?
Кто что слышал по этому поводу, поделитесь плиз.
18.02.03 18:22: Перенесено модератором из '.NET' в Философию Программирования — ХД
Re: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, flatch, Вы писали:
F>Планирует ли MS в новой версии .NET добавить в C# поддержку шаблонов и множественного наследования классов? F>Или, может, в будущем они планируют?
Про C# читал на сайте производителя, что в следующей версии будут аналоги шаблонов, а вот насчет множественного наследования сильно сомневаюсь.
Re: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, flatch, Вы писали:
F>Планирует ли MS в новой версии .NET добавить в C# поддержку шаблонов
поддержка шаблонов, ьудет точно.
и множественного наследования классов?
Не этого не будет, т.к. нет смысла, есть множественное наследоваие интерфейсов. Они с самого начала не стали делать множественное наследовние классов, чтобы не было путаницы как VC++.
Re[2]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, darkwolf, Вы писали:
D>Здравствуйте, flatch, Вы писали:
F>>Планирует ли MS в новой версии .NET добавить в C# поддержку шаблонов D>поддержка шаблонов, ьудет точно.
D> и множественного наследования классов? D>Не этого не будет, т.к. нет смысла, есть множественное наследоваие интерфейсов. Они с самого начала не стали делать множественное наследовние классов, чтобы не было путаницы как VC++.
"множественное наследоваие интерфейсов"
Нет никакого множественного наследование интерфейсов. Интерфейсы не содержат кода, от них ничего не может наследоваться. Они служат только для того, чтобы один объект мог быть представлен в разных ролях. Иначе полиморфизм работал бы только на одной ветке иерархии.
Java/C# это языки со строго одиночным наследованием, и никак иначе.
Здравствуйте, _vovin, Вы писали:
V>Нет никакого множественного наследование интерфейсов. Интерфейсы не содержат кода, от них ничего не может наследоваться.
Наследоваться, помимо реализации, может еще и интерфейс. Так что когда пишут так
interface IA : IB, IC
это именно множественное наследование интерфейсов
V> Они служат только для того, чтобы один объект мог быть представлен в разных ролях.
V>>Нет никакого множественного наследование интерфейсов. Интерфейсы не содержат кода, от них ничего не может наследоваться.
AVK>Наследоваться, помимо реализации, может еще и интерфейс. Так что когда пишут так AVK>
AVK>interface IA : IB, IC
AVK>
AVK>это именно множественное наследование интерфейсов
Я бы сказал, что это операция композиции интерфейсов. Наследование несет определенную смысловую нагрузку, связянную с
приобретением данных/кода предка.
Если darkwolf имеет в виду именно композицию интерфейсов, тогда вопрос снимается. Извиняюсь, если не так понял.
AVK> V>> Они служат только для того, чтобы один объект мог быть представлен в разных ролях.
AVK>Они много для чего нужны. Не только для этого.
V>>"множественное наследоваие интерфейсов" V>>Нет никакого множественного наследование интерфейсов.
МС> "... нет никакой ложки ..." (ц) Матрица
V>>Интерфейсы не содержат кода, от них ничего не может наследоваться.
МС> от них может наследоваться... хм... интерфейс...
V>>Java/C# это языки со строго одиночным наследованием, и никак иначе.
МС> имплементации (реализации (для ревнителей чистоты русского языка))
V>Я бы сказал, что это операция композиции интерфейсов. Наследование несет определенную смысловую нагрузку, связянную с V>приобретением данных/кода предка.
То, о чем вы говорите, называется наследованием реализации. То о чем говорит AndrewVK -- наследование интерфейса. И то, и другое -- наследование.
An interface can inherit from zero or more interfaces, which are called the explicit base interfaces of the interface
Если по твоему inherit переводится как композиция то тогда конечно.
V>Наследование несет определенную смысловую нагрузку, связянную с V>приобретением данных/кода предка.
Наследование означает только то что некая сущность приобретает некие свойства от своего родителя и ничего больше. То о чем ты говоришь ты сам придумал. Никогда термин наследование не означал наследование именно кода.
AVK>>Они много для чего нужны. Не только для этого.
V>Да, все это полезные дополнения.
Ну неизвестно что и к чему дополнение. Интерфейс это максимально абстрагированный интерфейс доступа к чему либо. А то что интерфейсы можно использовать в качестве механизма виртуального доступа без изменения иерархии наследования это уже следствие. Интерфейс может накрывать уже существующие методы, реализацией интерфейса может быть статический метод, часть реализации интерфейса может быть недоступна из интерфейса реализующего класса и т.д. Так что не надо сужать понятие интерфейса, оно куда шире. Можешь воспринимать интерфейс как маску, которую надевает класс, чтобы казаться кем то.
Здравствуйте, Lloyd, Вы писали:
L>То, о чем вы говорите, называется наследованием реализации. То о чем говорит AndrewVK -- наследование интерфейса. И то, и другое -- наследование.
Смею заметить что я не говорил что наследование это именно наследование интерфейса. Наследование интерфейса это один из способов наследования. Наследоваться может что угодно, не только интерфейс или код.
И еще, об этом речь недавно велась, но все же. Реализация классом интерфейса ни в коем случае наследованием не является.
Здравствуйте, AndrewVK, Вы писали:
AVK>И еще, об этом речь недавно велась, но все же. Реализация классом интерфейса ни в коем случае наследованием не является.
Повторяю для тех, кто в танке: Реализация классом интерфейса == Наследование интерфейса.
Это общепринятый термин и не надо пытаться сопоставлять его семантику и этимологию. Этимология не обязана соответствовать семантике.
Здравствуйте, Lloyd, Вы писали:
L>Повторяю для тех, кто в танке: Реализация классом интерфейса == Наследование интерфейса. L>Это общепринятый термин и не надо пытаться сопоставлять его семантику и этимологию. Этимология не обязана соответствовать семантике.
Абсолютно не соответствует истине.
Реализация классом интерфейса — это "реализация интерфейса" или "выполнение контракта".
Никакого отношения к "наследованию реализации" не имеет, кроме как схожести механизмов реализации "наследования" и "реализации".
Но ни один грамотный человек, например, не поставит знак равенства между "отношением генерализации" и "ассоциацией 1:1", хотя реализуются эти механизмы в физической модели часто одинаково.
Точно также и наследование с реализацией. Реализация интерфейса фактически сводится к таблицам виртуальных методов, но разница есть, и она концептуальная.
Здравствуйте, Akzhan, Вы писали:
A>Здравствуйте, Lloyd, Вы писали:
L>>Повторяю для тех, кто в танке: Реализация классом интерфейса == Наследование интерфейса. L>>Это общепринятый термин и не надо пытаться сопоставлять его семантику и этимологию. Этимология не обязана соответствовать семантике.
A>Абсолютно не соответствует истине. A>Реализация классом интерфейса — это "реализация интерфейса" или "выполнение контракта". A>Никакого отношения к "наследованию реализации" не имеет, кроме как схожести механизмов реализации "наследования" и "реализации".
Акжан, вы недостаточно внимательно прочитали мое послание. Я же явно указал, что семантика и этимолигия слова(термина) не обязаны соотвветствовать друг другу. Вы же взяли и свалили их в одну кучу.
Поясню, что я имею в виду.
И "наследование реализации" и "наследование интерфейса"-- суть термины. У них есть вполне конкретное значение.
Первое -- понятно что такое.
Второе -- это то, что многие (в том числе и вы) называют "реализацией интерфейса" или "выполнением контракта".
Увидив в этих двух теминах общее слове "наследование" (этимология). Вы с радостью набросились на него и начали доказывать, что наследование реализации и реализация интерфейса -- разные вещи (семантика). С тем, что это разные вещи, я абсолютно согласем.
Ваша ошибка была в том, что вы не восприняли эти термины именно как термины, а пытались из их "звучания" выудить какой-то дополнительный смысл. Не всегода стоит делать это. Иногда стоит и почитать книжки, в которых эти термины объяснялись.
A>Но ни один грамотный человек, например, не поставит знак равенства между "отношением генерализации" и "ассоциацией 1:1", хотя реализуются эти механизмы в физической модели часто одинаково.
A>Точно также и наследование с реализацией. Реализация интерфейса фактически сводится к таблицам виртуальных методов, но разница есть, и она концептуальная.
Кто бы спорил.
Re[2]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, henson, Вы писали:
H>Здравствуйте, flatch, Вы писали:
F>>Планирует ли MS в новой версии .NET добавить в C# поддержку шаблонов и множественного наследования классов? F>>Или, может, в будущем они планируют?
H>Про C# читал на сайте производителя, что в следующей версии будут аналоги шаблонов, а вот насчет множественного наследования сильно сомневаюсь.
Почитал я про .NET generics. Первое впечатление было: "обманули!" Обещали одно, а подсовывают совсем другое. Много было разговоров о том, что .NET generics будут мощнее тех, что предложены для Java. Сейчас же кажется, что единственное отличие от Java состоит в том, что generics в .NET будут поддерживать простые типы.
Основная идея остается одинаковой: про типы параметризации runtime не знает ничего, поэтому они считаются System.Object'ами.
Например, такое невозможно:
public class Dictionary<KeyType, ValType>
{
public void Add(KeyType key, ValType val)
{
...
switch(key.CompareTo(x)) // CompareTo() doesn't exist for KeyType
{
}
...
}
}
Нужно будет использовать constraints:
public class Dictionary<KeyType, ValType> where KeyType : IComparable
Понятия специализации для generics нет, typedef нет, generics для отдельных методов тоже нет.
Общее впечатление такое, что generics будут использоваться только для чего-нибудь простого вроде реализации типизированных коллекций.
Re[3]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, alexkro, Вы писали:
A>Например, такое невозможно:...
Честно говоря не ясно почему.
A>Понятия специализации для generics нет, typedef нет, generics для отдельных методов тоже нет.
Ну и на фиг все жто? Разве что для методов можно было бы оставить.
A>Общее впечатление такое, что generics будут использоваться только для чего-нибудь простого вроде реализации типизированных коллекций.
Дык вся соль в том, что в С++ шаблоны давно превратились из средства создания полиморфных алгоритмов в средства исправления проблем языка. Ух лучше пусть сам язык будет более стройным. К тому же у них есть еще одна очень важная задача. Им нужно сохранить в Шарпе простоту. Если насувать всех приколов из С++ в Шарп, то чем тогда Шарп будет лучше С++? С++ ведь никто не отменял! Хочешь выпендриваться создавай проект на МС++. Он уже в VS.NET 2003 очень прилично стал выглядеть.
... << RSDN@Home 1.0 beta 4 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Будут ли шаблоны и множественное наследование в CLR?
Здравствуйте, alexkro, Вы писали:
A>Почитал я про .NET generics. Первое впечатление было: "обманули!" Обещали одно, а подсовывают совсем другое. Много было разговоров о том, что .NET generics будут мощнее тех, что предложены для Java. Сейчас же кажется, что единственное отличие от Java состоит в том, что generics в .NET будут поддерживать простые типы.
A>Основная идея остается одинаковой: про типы параметризации runtime не знает ничего, поэтому они считаются System.Object'ами.
Плохо читал. Главное отличие дженериков в джаве от дженериков в дотнете именно в том что последние реально существуют в рантайме. Поищи в поиске, тут как то эта тема подробно обсасывалась, с примерами кода.
