Perhaps I am stirring up quite a bit of controversy with this statement, but I believe the lack of support for multiple inheritance in our type system is the single biggest contributor to the complexity of the .NET Framework. When we designed the type system, we explicitly decided not to add support for multiple inheritance so as to provide simplicity. In retrospect, this decision had the exact opposite effect. The lack of multiple inheritance forced us to add the concept of interfaces, which in turn are responsible for problems with the evolution of the framework, deeper inheritance hierarchies, and many other problems.
Re[6]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, HrorH, Вы писали: HH>А почему компилятор не может отличить название переменной от ключевого слова, как это он делает например с async?
Потому что async в качестве ключевого слова встречается только там, где не может стоять никакая переменная или имя типа.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, AlexRK, Вы писали: ARK>Кстати, пришло в голову — так надо было бы сделать динамическую диспетчеризацию для методов расширения, т.е. выбор extension-метода по реальному типу параметра this, а не статическому. Вроде особых подводных камней тут не должно быть.
Навскидку, это открывает потенциальную дверь в бесконечность. Поведение кода может произвольно измениться просто из-за того, что в домен загрузили новую сборку с более подходящим extension.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, Sinclair, Вы писали:
S>Потому что async в качестве ключевого слова встречается только там, где не может стоять никакая переменная или имя типа.
Так вроде бы и с trait также
public trait Foo
{
...
}
какая тут может стоять переменная или имя типа, чего-то не могу въехать.
Re[2]: [Ann] Next big thing in c#: default interface methods
V>The C# Programming Language
V>Krzysztof Cwalina V>
V>Perhaps I am stirring up quite a bit of controversy with this statement, but I believe the lack of support for multiple inheritance in our type system is the single biggest contributor to the complexity of the .NET Framework. When we designed the type system, we explicitly decided not to add support for multiple inheritance so as to provide simplicity. In retrospect, this decision had the exact opposite effect. The lack of multiple inheritance forced us to add the concept of interfaces, which in turn are responsible for problems with the evolution of the framework, deeper inheritance hierarchies, and many other problems.
Сильно. Только если бы они с самого начала решили по-другому, неизвестно, оказался бы хрен слаще редьки.
Re[8]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, HrorH, Вы писали:
HH>Здравствуйте, Sinclair, Вы писали:
S>>Потому что async в качестве ключевого слова встречается только там, где не может стоять никакая переменная или имя типа. HH>Так вроде бы и с trait также
HH>
HH> public trait Foo
HH> {
HH> ...
HH> }
HH>
HH>какая тут может стоять переменная или имя типа, чего-то не могу въехать.
В текущем C# это компилируется Ок:
public class Test
{
public class trait { }
public trait IFoo { get; set;}
}
Попробуйте заставить это скомпилироваться в вашем гипотетическом C# с ключевым словом trait.
Прямолинейная реализация приведёт к поведению, такому же как сейчас для
public class Test
{
public class interface { }
public interface IFoo { get; set;}
}
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, Sinclair, Вы писали:
S>Попробуйте заставить это скомпилироваться в вашем гипотетическом C# с ключевым словом trait.
Если проблема только с вложенными trait, то их можно просто запретить.
Тем более что непонятно, какая от них польза. По крайней мере вложенных интерфейсов я чего-то видел немного.
Re: [Ann] Next big thing in c#: default interface methods
Здравствуйте, Sinix, Вы писали:
S>Кто там хотел трайты-миксины? S>Неплохой ликбез по сабжу, тынц и тынц. Также см тут.
S>
S>interface IA
S>{
S> void M() { WriteLine("IA.M"); }
S>}
S>class C : IA { } // OK
S>// ...
Есть в Delphi есть директива implements
[q]
Случается, что реализация интерфейса содержится во вложенном объекте класса. Тогда не требуется программировать реализацию интерфейса путем замыкания каждого метода интерфеса на соответствующий метод вложенного объекта. Достаточно делегировать реализацию интерфейса вложенному объекту с помощью директивы implements:
[/q]
type
[pascal]
TTextParser = class(TInterfacedObject, ITextReader)
...
FTextReader: ITextReader;
property TextReader: ITextReader read FTextReader implements ITextReader;
...
end;
[/pascal]
[cs]
В этом примере интерфейс ITextReader в классе TTextParser реализуется не самим классом, а его внутренней переменной FTextReader.
Очевидно, что внутренний объект должен быть совместим с реализуемым интерфейсом.
Вот это было бы интересно и ближе к множественному наследованию.
При этом можно делать автоматические обертки по образу и подобиb fody PropertyChanged
Здравствуйте, Silver_S, Вы писали:
S_S>Здравствуйте, VladD2, Вы писали:
S_S>Собирать из кусочков хорошо, только вот бы еще одну фичу из С++ — private наследование интерфейсов. Почему не предлагают, не уж то это только мне требуется? S_S>Уже не мало классов пришлось написать, которым в конструктор передается по 3-4 делегата, кроме прочего. S_S>Можно было бы один интерфейс передать. Но как его реализовывать в классе-клиенте этой штуки, если используется приватно, и нельзя поганить класс-клиент публичным наследованием? S_S>Альтернатива только в классе-клиенте private nested класс делать, в нем интерфейс реализуется, методы интерфейса вызывают поля-делегаты, эти поля заполняются классом-клиентом. Хотя бы так сделали без изменения CLR.
Это с самых первых версий есть в VB.NET. Можно просто использовать вместо C# где необходимо .
Re[5]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, Sinclair, Вы писали:
HH>>Если кто-то хочет дефолтную реализацию, сделали бы для них ключевое слово trait. S>И сломали бы неизвестное количество проектов, где есть переменные и мемберы с именем trait?
Вот самая из натянутых отговорок, честно.
С современными средами разработки и методами рефакторинга это наименьшая из проблем.
Могли бы ключ компилятора в конце концов сделать какой или еще чего.
Re[6]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, AngeL B., Вы писали:
AB>Вот самая из натянутых отговорок, честно.
Это вам кажется. AB>С современными средами разработки и методами рефакторинга это наименьшая из проблем.
И это вам кажется. Далеко не всегда есть возможность поправить исходник. AB>Могли бы ключ компилятора в конце концов сделать какой или еще чего.
А это — вообще тупик. С тем же успехом можно просто не выпускать фичу. Стоимость тестирования возрастает на ровном месте вдвое: ведь нам надо проверить, что все тесты работают корректно с обоими ключами компилятора.
При этом те, кому нужен ключ, по факту не применяют новую фичу совсем — т.е. ездят на старой версии компилятора.
Ведь в шарпе нет частичной компиляции — то есть если у нас "сломан" один файл в проекте, то отключить фичу придётся во всём проекте.
Вы бы почитали блоги Липперта, что ли. Он там очень много вещей подробно обсуждает с точки зрения команды компилятора.
Очень легко принимать такие решения, когда у твоего продукта полтора человека пользователей, или ты опенсорсник, которому наплевать на свою аудиторию, и никаких обязательств у тебя перед ними нет.
А когда ты работаешь в коммерческой компании, то backwards compatibility становится ночным кошмаром.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, Sinclair, Вы писали:
S>Очень легко принимать такие решения, когда у твоего продукта полтора человека пользователей, или ты опенсорсник, которому наплевать на свою аудиторию, и никаких обязательств у тебя перед ними нет. S>А когда ты работаешь в коммерческой компании, то backwards compatibility становится ночным кошмаром.
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, Sinix, Вы писали:
Doc>Блин. Вот чего меньше всего хотелось это увидеть код имплементации в интерфейсе. Doc>Зачем мешать контракт и реализацию? Печаль
Контракт это не обязательно только безликие сигнатуры. В него так же могут быть включены некоторые дополнительные утверждения, нарушив которые ты нарушаешь LSP.
Поэтому народ придумывает всякие code contracts и т.п. Часть таких утверждений можно закодировать в виде дефолтных реализаций или методах расширения.
Например, утверждение, что для чисел выполняется x-y==x+(-y), поэтому бинарный минус можно реализовать через унарный и операцию сложения.
Но если его сделать методом расширения, ты теряешь возможность реализовать его более эффективным способом для BigInteger.
Или вот:
interface IEnumerable<T>
{
//...bool Contains(T value)
{
foreach(var item in this)
{
if(item == value)
return true;
}
return false;
}
}
class HashSet<T>: IEnumerable<T>, ISet<T>
{
bool Contains(T value)
{
//более эффективная реализация, но с тем же результатом
}
}
void Do(IEnumerable<T> items)
{
b = items.Contains(...);
//вместо такого:if(items is ISet<T>)
b = (ISet<T>)items.Contains(...);
else if(items is SomethingElseThatIsSupposedToHaveEffectiveContains<T>)
b = ...
}
