Здравствуйте, TK, Вы писали:
TK>Здравствуйте, AlexRK, Вы писали:
TK>Теперь простое задание: надо добавить в интерфейс IOut новый метод PrintString2. Класс B должен содержать собственную реализацию PrintString2. TK>Класс C — Legacy и его трогать нельзя.
Так если его нельзя трогать, как может речь идти о добавлении нового метода? Значит будет новый интерфейс, который класс C поддерживать не будет.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[10]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, AlexRK, Вы писали:
TK>>Теперь простое задание: надо добавить в интерфейс IOut новый метод PrintString2. Класс B должен содержать собственную реализацию PrintString2. TK>>Класс C — Legacy и его трогать нельзя.
TK>>
TK>>IOut out1 = new C();
TK>>IOut out2 = new B();
TK>>out1.PrintString2(); // Default PrintString2
TK>>out2.PrintString2(); // Updated PrintString2
TK>>
ARK>
ARK>static class OldGoodMixin
ARK>{
ARK> public static void PrintString2(this IOut o)
ARK> {
ARK> // ...
ARK> }
ARK>}
ARK>public class B: IOut
ARK>{
ARK> public void PrintString2()
ARK> {
ARK> // ...
ARK> }
ARK>}
ARK>
Запускать будем? Ключевой момент я жирным выделил
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[10]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, hardcase, Вы писали:
TK>>Теперь простое задание: надо добавить в интерфейс IOut новый метод PrintString2. Класс B должен содержать собственную реализацию PrintString2. TK>>Класс C — Legacy и его трогать нельзя.
H>Так если его нельзя трогать, как может речь идти о добавлении нового метода? Значит будет новый интерфейс, который класс C поддерживать не будет.
Так в этом то и смысл: пишете тут — добавляется там
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[11]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, hardcase, Вы писали:
TK>>Так в этом то и смысл: пишете тут — добавляется там H>Я так понял исходники C доступны, только не понятно, почему их менять не нельзя, а код интерфейса — можно.
Посмотрите как это в java было — просто в какой-то момент расширили базовые библиотечные интерфейсы при этом не поломав существующий код.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re[8]: [Ann] Next big thing in c#: default interface methods
ARK>public interface IOut
ARK>{
ARK> void PrintChar(char c);
ARK>}
ARK>static class OldGoodMixin
ARK>{
ARK> public static void PrintString(this IOut o, string chars)
ARK> {
ARK> foreach(var c in chars)
ARK> o.PrintChar(c);
ARK> }
ARK>}
ARK>public class C: IOut
ARK>{
ARK> public void PrintChar(char c)
ARK> {
ARK> System.Console.Write(c);
ARK> }
ARK>}
ARK>
Да, верно. Extension методы — мегакруто. Но есть и нюансы:
public class C: IOut
{
public void PrintChar(char c)
{
using(w = StreamWriter.OpenWrite("out.txt", true))
w.Write(c);
}
public void PrintString(string chars)
{
using(w = StreamWriter.OpenWrite("out.txt", true))
w.Write(chars);
}
}
public static class D
{
public static void Test()
{
var c = new C();
TestClass(c);
TestIntf(c);
}
public static void TestClass(C output)
{
output.PrintString("Hello, world!");
}
public static void TestIntf(IOut output)
{
output.PrintString("Hello, world!"); // упс - мы вызываем дефолтную неэффективную реализацию вместо оптимизированной удобной.
}
}
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: [Ann] Next big thing in c#: default interface methods
Здравствуйте, Doc, Вы писали: Doc>Зачем мешать контракт и реализацию? Печаль
Затем, что мир не делится на чёрное и белое, или "контракт vs реализация".
Например, IEnumerable.Count — это контракт или реализация?
С одной стороны, неохота включать Count в контракт IEnumerable, потому что это обяжет всех подряд заниматься его написанием.
С другой стороны, без него неудобно.
С третьей стороны, в 95% случаев нас устроит дефолтная реализация, выраженная через пересчёт результатов GetEnumerator.
С четвёртой стороны, в 5% случаев она нас не устраивает по соображениям производительности, и мы хотим иметь возможность реализовать её эффективнее.
В итоге, без концепции "дефолтной реализации" у нас одно из трёх:
1. Каждый клиент по месту припиливает foreach(var i in e) count++
2. 19 из 20 реализаторов IEnumerable вынужден выписывать foreach(var i in this) count++; и только один пишет там что-то более умное (например, this._count;)
3. Реализация Enumerable.Count развлекается игрой в угадайку типа if (arg is IList) { return (IList(arg)).Count;}
В итоге, у нас получается куча вот таких вот "утилитных методов", которые занимают промежуточное положение — клиент требует, чтобы они были, а вот сервер не должен быть обязан их предоставлять.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: [Ann] Next big thing in c#: default interface methods
Если кто-то хочет дефолтную реализацию, сделали бы для них ключевое слово trait.
А для тех кто не хочет мешать контракт и реализацию, оставили бы в языке хотя бы одно ключевое слово, которое позволяет задать чистый контракт.
Re[3]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, Sinclair, Вы писали:
Doc>>Зачем мешать контракт и реализацию? Печаль S>Затем, что мир не делится на чёрное и белое, или "контракт vs реализация".
Вот ровно с такой же мотивацией можно смешать все что угодно.
А по факту — контракт это абстракция, реализация ... ну тут само слово говорит за себя.
Изначально интерфейсы отделили от реализации ради абстракции и вот сейчас просто решили пойти на наперекор самой идеи интерфейсов.
S>Например, IEnumerable.Count — это контракт или реализация?
Вопрос не корректный, т.к. мы все знаем что это extension метод. Но он не является частью контракта интерфейсов с которыми работает.
По сути это имплементация, которая полагается на контракт IEnumerable.
S>В итоге, у нас получается куча вот таких вот "утилитных методов", которые занимают промежуточное положение — клиент требует, чтобы они были, а вот сервер не должен быть обязан их предоставлять.
И для его есть вполне удобные extension методы, которые решают как раз вопрос вот таких Count.
Нужны дефолтные методы? Есть abstract class.
Зачем при этом смешивать абстракции и реализации — не ясно.
Re[4]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, HrorH, Вы писали:
HH>Если кто-то хочет дефолтную реализацию, сделали бы для них ключевое слово trait.
Тут проблема в том, что в CLS нет трайтов.
Т.е. или под трайтами прятать те же интерфейсы (и для клиентов библиотеки они будут выглядеть как интерфейсы, помеченные служебным атритутом), или получаем просто синтаксический сахар, без бинарной совместимости.
Re[9]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, Sinclair, Вы писали:
S>Да, верно. Extension методы — мегакруто. Но есть и нюансы:
Кстати, пришло в голову — так надо было бы сделать динамическую диспетчеризацию для методов расширения, т.е. выбор extension-метода по реальному типу параметра this, а не статическому. Вроде особых подводных камней тут не должно быть.
Re[4]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, HrorH, Вы писали:
HH>Если кто-то хочет дефолтную реализацию, сделали бы для них ключевое слово trait.
И сломали бы неизвестное количество проектов, где есть переменные и мемберы с именем trait?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, Sinclair, Вы писали:
S>И сломали бы неизвестное количество проектов, где есть переменные и мемберы с именем trait?
А почему компилятор не может отличить название переменной от ключевого слова, как это он делает например с async?
Re[3]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, VladD2, Вы писали:
VD>... Можно разбить все на атомы и собирать нужные конфигурации из готовых частей. VD>Такой подход давно используется в С++.
Собирать из кусочков хорошо, только вот бы еще одну фичу из С++ — private наследование интерфейсов. Почему не предлагают, не уж то это только мне требуется?
Уже не мало классов пришлось написать, которым в конструктор передается по 3-4 делегата, кроме прочего.
Можно было бы один интерфейс передать. Но как его реализовывать в классе-клиенте этой штуки, если используется приватно, и нельзя поганить класс-клиент публичным наследованием?
Альтернатива только в классе-клиенте private nested класс делать, в нем интерфейс реализуется, методы интерфейса вызывают поля-делегаты, эти поля заполняются классом-клиентом. Хотя бы так сделали без изменения CLR.
private интерфейс смысла не имеет как интерфейс (но имеет как контракт — т.е. выдаем публичные методы без публикации интерфейса). Но это не так как работает C#. Короче — конечно же ты не один. Самый лучший — C++ наверное, но вообще нужно ещё больше. Нужны user defined access tokens/scopes (времени компиляции), для доступа к членам. Но это абсолютно зависит от задач. Кому-то это покажется бредом. Да, кстати — кому показалось — идите, не задерживайтесь.
Re[4]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, Silver_S, Вы писали:
S_S>Собирать из кусочков хорошо, только вот бы еще одну фичу из С++ — private наследование интерфейсов. Почему не предлагают, не уж то это только мне требуется?
Похоже — да. Я даже когда писал на плюсах его не использовал. Это даже звучит как оксюморон. Интерфейс подразумевает публичность, а тут вдруг приватное его наследование. Это или не наследование, или не интерфейс.
S_S>Уже не мало классов пришлось написать, которым в конструктор передается по 3-4 делегата, кроме прочего. S_S>Можно было бы один интерфейс передать. Но как его реализовывать в классе-клиенте этой штуки, если используется приватно, и нельзя поганить класс-клиент публичным наследованием?
Делегаты ты в поля кладешь и ничего вроде. Чем интерфейс отличается в данном случае?
S_S>Альтернатива только в классе-клиенте private nested класс делать, в нем интерфейс реализуется, методы интерфейса вызывают поля-делегаты, эти поля заполняются классом-клиентом. Хотя бы так сделали без изменения CLR.
Что-то все очень сложно. Можно просто реализовывать интерфейс или базовый класс во вложенном приватном классе. Все детали останутся в нем, а возвращен будет публичный интерфейс. Возможно я не очень понимаю решаемой задачи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Ann] Next big thing in c#: default interface methods
Здравствуйте, VladD2, Вы писали:
VD>Делегаты ты в поля кладешь и ничего вроде. Чем интерфейс отличается в данном случае?
Только тем что не так громоздко выглядит, как если: 4 делегата передавать в конструктор. Для этих делегатов имена параметров задать нельзя (иногда это очень плохо) голые Func, хорошо если делегаты без ref,out. Либо явно объявлять 4 delegate. Еще и 4 поля и 4 присвоения.
Ну лучше бы выглядел код, с interface, когда так много делегатов передается.
S_S>>Альтернатива только в классе-клиенте private nested класс делать, в нем интерфейс реализуется, VD>Что-то все очень сложно. Можно просто реализовывать интерфейс или базовый класс во вложенном приватном классе. Все детали останутся в нем, а возвращен будет публичный интерфейс. Возможно я не очень понимаю решаемой задачи.
Я об этом и говорю — во вложенном приватном классе, и в этот вложенный приватный класс передавать ссылку на родительский класс. Компактнее бы это все выглядело как private наследование.
Смысл в том что наружу этот интерфейс не показывается, он передается только агрегированным приватным объектам.
Такое имеется ввиду ( в конструктор Some надо передавать IInterface1):
class Parent
{
private class Interface1Impl : IInterface1
{
public Interface1Impl(Parent p)
{
_p = p;
}
Parent _p; //Для реализации интерфейса нужен доступ в Parent
}
public Parent()
{
_interface1Impl=new Interface1Impl(this);
_some = new Some(_interface1Impl);
}
private Some _some;
private Interface1Impl _interface1Impl;
}
Было бы private наследование, никому бы не мешало, когда не надо. А здесь бы можно было так:
class Parent: private IInterface1
{
public Parent()
{
_some = new Some(this);
}
private Some _some;
}
Зачем вынесен Some из Parent это другой вопрос — этот Some используется в нескольких Parent, и к тому же должен быть в другой более абстрактной сборке.
