Здравствуйте, все, вы писали [много]

Я извиняюсь, а чего хотелось-то, массив просуммировать, что ли?

Если что —

Здравствуйте, hi_octane, Вы писали:

_>Так это он шейпы переименовал. И добавил моноиды в презентацию — чтобы хипстеры и менеджеры были хэппи. Так легче видимо эти шейпы будет пропихнуть.

Исходно это все от классов типов Хаскеля растет, отсюда и моноиды.

_>Да нужны. Нам их ещё в C#9 обещали.

По мне так данная реализация убога. Нужно делать как в Go, т.е. чтобы вместо обычного интерфейса можно было был передать любой объект у которого есть все члены этого интерфейса (совпадающие по имени + сигнатура). Тогда этот костыль будет не нужен.

А так получается половинчатое решение. А половинчатое оно потому, что делается средствами компилятора, в то время как для полноценной реализации нужна поддержка рантайма.

Здравствуйте, VladD2, Вы писали:

VD>По мне так данная реализация убога. Нужно делать как в Go, т.е. чтобы вместо обычного интерфейса можно было был передать любой объект у которого есть все члены этого интерфейса (совпадающие по имени + сигнатура). Тогда этот костыль будет не нужен.

С точки зрения перегрузки методов так и есть берутся текущие, но ты можешь переопределить в ролях.
Если не интерфейс, то что будет выступать контрактом?

Здравствуйте, Serginio1, Вы писали:

VD>>По мне так данная реализация убога. Нужно делать как в Go, т.е. чтобы вместо обычного интерфейса можно было был передать любой объект у которого есть все члены этого интерфейса (совпадающие по имени + сигнатура). Тогда этот костыль будет не нужен.
S> С точки зрения перегрузки методов так и есть берутся текущие, но ты можешь переопределить в ролях.
S>Если не интерфейс, то что будет выступать контрактом?
Дык интерфейс и будет. Влад, как я понял, хочет структурную типизацию.
ИМХО — нафиг. В C#9 реализовать интерфейс (при наличии в типе всех членов интерфейса) — можно одной строчкой. extention MyClassExt intends MyClass: IMyIntf {} см тут

Здравствуйте, Jack128, Вы писали:

J>Здравствуйте, Serginio1, Вы писали:

VD>>>По мне так данная реализация убога. Нужно делать как в Go, т.е. чтобы вместо обычного интерфейса можно было был передать любой объект у которого есть все члены этого интерфейса (совпадающие по имени + сигнатура). Тогда этот костыль будет не нужен.
S>> С точки зрения перегрузки методов так и есть берутся текущие, но ты можешь переопределить в ролях.
S>>Если не интерфейс, то что будет выступать контрактом?
J>Дык интерфейс и будет. Влад, как я понял, хочет структурную типизацию.
J>ИМХО — нафиг. В C#9 реализовать интерфейс (при наличии в типе всех членов интерфейса) — можно одной строчкой. extention MyClassExt intends MyClass: IMyIntf {} см тут

Дык и чем role отличается от extention ?
Для роле нужно указать тип, для extention он выводится

Здравствуйте, Serginio1, Вы писали:

S>С точки зрения перегрузки методов так и есть берутся текущие, но ты можешь переопределить в ролях.
S>Если не интерфейс, то что будет выступать контрактом?

Ты, похоже, ничего из написанного мной не понял. Посмотри как в Go реализованы интерфейсы. Там какие-то роли не нужны. Любой объект обладающий набором членов совпадающим с набором членов интерфейса считается реализующим этот интерфейс (утиная типизация). Есть у тебя интерфейс:

interface IFoo
{
  void Bar();
}

И есть объект:

class Baz
{
  void X() {}
  void Bar() {}
}

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

Все! Никакие роли не нужны! Если надо добавить реализацию недостающих методов можно пользоваться наследованием. Ну, разве что для запечатанных типов роли нужны для обхода запечатанности.

А тут нужно каждый раз придется писать кучу кода руками. Конечно, лучше чем ничего. Но по сравнению с Go — хуже.

Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Jack128, Вы писали:

J>>Здравствуйте, Serginio1, Вы писали:

VD>>>>По мне так данная реализация убога. Нужно делать как в Go, т.е. чтобы вместо обычного интерфейса можно было был передать любой объект у которого есть все члены этого интерфейса (совпадающие по имени + сигнатура). Тогда этот костыль будет не нужен.
S>>> С точки зрения перегрузки методов так и есть берутся текущие, но ты можешь переопределить в ролях.
S>>>Если не интерфейс, то что будет выступать контрактом?
J>>Дык интерфейс и будет. Влад, как я понял, хочет структурную типизацию.
J>>ИМХО — нафиг. В C#9 реализовать интерфейс (при наличии в типе всех членов интерфейса) — можно одной строчкой. extention MyClassExt intends MyClass: IMyIntf {} см тут

S> Дык и чем role отличается от extention ?
S> Для роле нужно указать тип, для extention он выводится

Ну вот как раз фича внешней реализации интерфейсов в новых экстеншенах сильно пересекается с областью использования ролей, ИМХО нужно оставлять что то одно.

Здравствуйте, VladD2, Вы писали:



VD>А тут нужно каждый раз придется писать кучу кода руками. Конечно, лучше чем ничего. Но по сравнению с Go — хуже.
Так для роли тоже самое просто прписал один раз и используй.

А если тебе захотелось переопределить какой то оператор то роли это позволяют. Например сравнение строк без учета регистров
А как с этим в GO?

Здравствуйте, VladD2, Вы писали:

VD>Объект типа Baz можно передать туда где требуется IFoo, так как Baz реализует все члены IFoo (в данном случае Bar).

Это сломает всю совместимость CLR, так что увы, но не в дотнете.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Это сломает всю совместимость CLR, так что увы, но не в дотнете.

А может для подобного DLR использовать?

Здравствуйте, Sharov, Вы писали:

S>А может для подобного DLR использовать?

А в DLR совместимых языках в основном структурная типизация в том или ином виде есть.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>А в DLR совместимых языках в основном структурная типизация в том или ином виде есть.

И у чем тогда проблема подтолкнуть утиную типизацию для интерфейсов в шарп?

Здравствуйте, VladD2, Вы писали:
VD>Все! Никакие роли не нужны! Если надо добавить реализацию недостающих методов можно пользоваться наследованием. Ну, разве что для запечатанных типов роли нужны для обхода запечатанности.
Тут есть пара нюансов.
1. Нужны не только экземплярные, но и статические методы. Например, operator +, он же op_Addition.
2. В классах типа System.Int32 нужных нам статических методов нет.

Здравствуйте, Sharov, Вы писали:

S>И у чем тогда проблема подтолкнуть утиную типизацию для интерфейсов в шарп?

В том что шарп это не динамика.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>А в DLR совместимых языках в основном структурная типизация в том или ином виде есть.

S>И у чем тогда проблема подтолкнуть утиную типизацию для интерфейсов в шарп?
Так роли это и делают.
Просто роли позволяют переопределить статические методы . Если не переопределил берутся текущие

Здравствуйте, Qbit86, Вы писали:

Q>

Q>[Benchmark(Baseline = true)]
Q>public int ReduceIntegers() => s_integers.Reduce(default(AdditiveInt32Monoid));

Q>[Benchmark]
Q>public int AggregateIntegers() => s_integers.Aggregate(0, (left, right) => left + right);

Q>

Стало интересно

        [Benchmark]
        public int SumIntegers() {
        int sum = 0;
        foreach(int i in s_integers) sum += i;
            return sum;
    }

представил как я смотрю на эти методы.
Да, без погружения в ФП их сразу не поймешь, да и в скорости в 10 раз проигрывают.

Здравствуйте, varenikAA, Вы писали:

AA>Roles in C#

В данный момент оно в таком состоянии: [Proposal]: Static abstract members in interfaces

Здравствуйте, varenikAA, Вы писали:

Ну не совсем они эффективно итераторы используют
http://rsdn.org/forum/flame.comp/7996919.1

Автор: Serginio1
Дата: 24.04.21