Optional Value. Уменьшение количества null reference-ов. - Архитектура программного обеспечения

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

G>А на деле не нужна.
Ковариантность нужна! Там где обычный полиморфизм + option логика = получаем необходимость ковариантности.

G>Я собственно и до .NET4 не испытывал проблем из-за отсутствия ковариантности интерфейсов, где надо проделывал приведение типа ручками.
Прописывать ковариантность ручками для option логики непозволительный синтаксический оверхед.

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

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

AP>>>А поскольку из-за желания ковариантности мы не может запретить создание других реализаций, то завязка на типы классов не очень хорошая идея.
S>>Другие реализации не нужны. Но запретить тебе их желать я не могу.
AP>Мне они тоже не нужны. Мое желание -- иметь ковариантность.

Ковариантности не нужен полиморфный метод.

interface IOptionalValue<out T>
{
    //TResult Process<TResult>(Func<T, TResult> f1, Func<TResult> f2);
}

class OptionalValue<T> : IOptionalValue<T>
{
    private OptionalValue() {}

    public sealed class NothingValue : OptionalValue<T> { }

    public sealed class JustValue : OptionalValue<T>
    {
        public readonly T Value;

        public JustValue(T value) { Value = value; }
    }
}

Потому завязка на типы классов ничуть не хуже полиморфизма в аспекте ковариантности.

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

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

G>>А на деле не нужна.
AP>Ковариантность нужна! Там где обычный полиморфизм + option логика = получаем необходимость ковариантности.
Удобна, но не необходима.

G>>Я собственно и до .NET4 не испытывал проблем из-за отсутствия ковариантности интерфейсов, где надо проделывал приведение типа ручками.
AP>Прописывать ковариантность ручками для option логики непозволительный синтаксический оверхед.
Что же непозволительного в лишнем методе?

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

G>>>Я собственно и до .NET4 не испытывал проблем из-за отсутствия ковариантности интерфейсов, где надо проделывал приведение типа ручками.
AP>>Прописывать ковариантность ручками для option логики непозволительный синтаксический оверхед.
S>Что же непозволительного в лишнем методе?
Там, наверное, еще тип указывать надо, так? или я ошибаюсь? Желательно код увидеть.

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

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

AP>>>Прописывать ковариантность ручками для option логики непозволительный синтаксический оверхед.
S>>Что же непозволительного в лишнем методе?
AP>Там, наверное, еще тип указывать надо, так? или я ошибаюсь? Желательно код увидеть.
С каких пор указание типа стало непозволительной роскошью для C#?

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

AP>>>>А поскольку из-за желания ковариантности мы не может запретить создание других реализаций, то завязка на типы классов не очень хорошая идея.
S>>>Другие реализации не нужны. Но запретить тебе их желать я не могу.
AP>>Мне они тоже не нужны. Мое желание -- иметь ковариантность.
S>Ковариантности не нужен полиморфный метод.
S>

S>interface IOptionalValue<out T>
S>{
S>    //TResult Process<TResult>(Func<T, TResult> f1, Func<TResult> f2);
S>}

S>class OptionalValue<T> : IOptionalValue<T>
S>{
S>    private OptionalValue() {}

S>    public sealed class NothingValue : OptionalValue<T> { }

S>    public sealed class JustValue : OptionalValue<T>
S>    {
S>        public readonly T Value;

S>        public JustValue(T value) { Value = value; }
S>    }
S>}
S>

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

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

AP>>>>Прописывать ковариантность ручками для option логики непозволительный синтаксический оверхед.
S>>>Что же непозволительного в лишнем методе?
AP>>Там, наверное, еще тип указывать надо, так? или я ошибаюсь? Желательно код увидеть.
S>С каких пор указание типа стало непозволительной роскошью для C#?
Непозволительная роскошь в контексте реализации option логики. Если будет большой синтаксический оверхед будет возникать естественное желание побаловаться nuul-ами, а потом и не заметишь, как они разрастутся.

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

S>>Потому завязка на типы классов ничуть не хуже полиморфизма в аспекте ковариантности.
AP>Ну в обсуждаемом вопросе все переплетается друг с другом. В таком варианте, да, ковариантность присутствует. Я думал, ты собираешься запрещать других наследников с помощью абстрактного класса вместо интерфейса. Если идем через интерфейс, то возможны другие наследники, а у тебя есть завязка в extension методах на конкретных наследников, что не хорошо.

Да, не хорошо. Потому ковариантность в шею!

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

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

AP>>>Там, наверное, еще тип указывать надо, так? или я ошибаюсь? Желательно код увидеть.
S>>С каких пор указание типа стало непозволительной роскошью для C#?
AP>Непозволительная роскошь в контексте реализации option логики. Если будет большой синтаксический оверхед будет возникать естественное желание побаловаться nuul-ами, а потом и не заметишь, как они разрастутся.

А я вообще эту кухню не воспринимаю серьезно в рамках C#-а. В F# создали довольно большую песочницу, где встретить null действительно сложно. Но как только выходишь за рамки этой песочницы и начинаешь взаимодействовать с FCL, null-ы все еще проблема. В C# вообще нет никакой песочницы, где бы не было null-ов.

Кроме этого, вряд ли в серьезном проекте, где разработчиков больше 3х, будет единодушие по поводу искоренения null-ов. Такое не исключено, но я не рассчитываю попасть в такой проект.

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

S>Кроме этого, вряд ли в серьезном проекте, где разработчиков больше 3х, будет единодушие по поводу искоренения null-ов. Такое не исключено, но я не рассчитываю попасть в такой проект.
Вопрос надо формулировать не как искоренение налов, а вот так. Каким образом реализовывать optional бизнес логику?

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

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

G>>>>>>Проблема этого интерфейса что он не энфорсит контракт, это при том что кроме Some\Just и None реализаций не нужно. Но я могу сколько угодно своих реализаций подсовывать.
AP>>>>>Это замечание незначительно само по себе,
G>>>>Да ну? Сломать контракт это фигня?
AP>>>Какой контракт? Ты вообще о чем? Нет у меня никакого контракта. Ломать нечего!
G>>

AP>Что тебя так рассмешило?
То что у тебя нет контракта.

G>>... а все вместе — нет.
AP>Код в студию.

Держи

class Ololo<T>: IOptionalValue<T>
{
    public TResult Process<TResult>(Func<T, TResult> existFunc, Func<TResult> notExistFunc)
    {
        return default(TResult);
    }
}

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

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

G>>А на деле не нужна.
AP>Ковариантность нужна! Там где обычный полиморфизм + option логика = получаем необходимость ковариантности.
Бред же.

G>>Я собственно и до .NET4 не испытывал проблем из-за отсутствия ковариантности интерфейсов, где надо проделывал приведение типа ручками.
AP>Прописывать ковариантность ручками для option логики непозволительный синтаксический оверхед.
Счегобы? Ты даже не смог пример привести где ковариантность была тебе необходима.

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

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

AP>>>>>Прописывать ковариантность ручками для option логики непозволительный синтаксический оверхед.
S>>>>Что же непозволительного в лишнем методе?
AP>>>Там, наверное, еще тип указывать надо, так? или я ошибаюсь? Желательно код увидеть.
S>>С каких пор указание типа стало непозволительной роскошью для C#?
AP>Непозволительная роскошь в контексте реализации option логики. Если будет большой синтаксический оверхед будет возникать естественное желание побаловаться nuul-ами, а потом и не заметишь, как они разрастутся.

Да приведи уже пример.

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

G>>>А на деле не нужна.
AP>>Ковариантность нужна! Там где обычный полиморфизм + option логика = получаем необходимость ковариантности.
G>Бред же.
В чем заключается бред, объяснить можешь?

G>>>Я собственно и до .NET4 не испытывал проблем из-за отсутствия ковариантности интерфейсов, где надо проделывал приведение типа ручками.
AP>>Прописывать ковариантность ручками для option логики непозволительный синтаксический оверхед.
G>Счегобы? Ты даже не смог пример привести где ковариантность была тебе необходима.
Не ври. Я не увидел зачем мне напрягаться. Пример потребует некоторых временных затрат. А ты опять не поймешь суть и прицепишься к несущественным моментам. Поэтому углубляться здесь на форуме в кастомные задачи я смысла не вижу. Если, действительно, есть желание, приходи к нам в офис, я тебе покажу код с моего экрана, а потом поговорим по коду.

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

G>>>... а все вместе — нет.
AP>>Код в студию.
G>Держи
G>

G>class Ololo<T>: IOptionalValue<T>
G>{
G>    public TResult Process<TResult>(Func<T, TResult> existFunc, Func<TResult> notExistFunc)
G>    {
G>        return default(TResult);
G>    }
G>}
G>

где, что не работает?

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

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

S>>Кроме этого, вряд ли в серьезном проекте, где разработчиков больше 3х, будет единодушие по поводу искоренения null-ов. Такое не исключено, но я не рассчитываю попасть в такой проект.
AP>Вопрос надо формулировать не как искоренение налов, а вот так. Каким образом реализовывать optional бизнес логику?

Так чтобы читать было удобно. Охота за налами не должна превращаться в самоцель. Осбенно в языке и фреймворке, заточенном на активное их использование.

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

S>>>Кроме этого, вряд ли в серьезном проекте, где разработчиков больше 3х, будет единодушие по поводу искоренения null-ов. Такое не исключено, но я не рассчитываю попасть в такой проект.
AP>>Вопрос надо формулировать не как искоренение налов, а вот так. Каким образом реализовывать optional бизнес логику?
S>Так чтобы читать было удобно. Охота за налами не должна превращаться в самоцель. Осбенно в языке и фреймворке, заточенном на активное их использование.
Читать код это самоцель? Я с кодом работаю, а это более широкое понятие.

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

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

S>>Так чтобы читать было удобно. Охота за налами не должна превращаться в самоцель. Осбенно в языке и фреймворке, заточенном на активное их использование.
AP>Читать код это самоцель? Я с кодом работаю, а это более широкое понятие.
Один?

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

G>Проблема в том что NRE вообще упадет.
А!
G>Рассмотрим код:

G>

G>var x = Method1().Method2().Method3().Method4();
G>

G>Если везде возвращаются ref-типы, то каждый из методов может вернуть null.
G>Можно использовать контракты чтобы доказать что null не вернется.
Это совсем другая задача, чем та, которую ты обсуждаешь дальше.
G>Но иногда все таки методы возвращают null и это является нормальным поведением, а нас во всей операции интересует только конечный результат, тогда хорошо бы иметь способ описать частичные вычисления (которые могут не вернуть результата). В других языках есть конструкции типа .?, которые возвращают null если выражение слева null, но далеко не всегда есть возможность возвращать null, например если результат — value-type.

G>Вот и реализуют абстракции типа Option, которые позволяют избежать использования null и водопроводного кода типа:

G>

G>var x1 = Method1();
G>if(x1 == null) return null;
G>var x2 = x1.Method2();
G>if(x2 == null) return null;
G>var x3 = x2.Method3();
G>if(x3 == null) return null;
G>return x3.Method4();
G>

Стесняюсь показаться ретроградом, но имхо этот "водопроводный" код менее многословен и более понятен, чем предложенная альтернатива. Можно показать мне, как классно будет записан вызов

var x = Method1().Method2().Method3().Method4();

так, чтобы в случае возврата null из любого из методов вместо NRE мы получили null в x?

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

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

G>>Вот и реализуют абстракции типа Option, которые позволяют избежать использования null и водопроводного кода типа:

G>>

G>>var x1 = Method1();
G>>if(x1 == null) return null;
G>>var x2 = x1.Method2();
G>>if(x2 == null) return null;
G>>var x3 = x2.Method3();
G>>if(x3 == null) return null;
G>>return x3.Method4();
G>>

S>Стесняюсь показаться ретроградом, но имхо этот "водопроводный" код менее многословен и более понятен, чем предложенная альтернатива. Можно показать мне, как классно будет записан вызов
S>

S>var x = Method1().Method2().Method3().Method4();
S>

S>так, чтобы в случае возврата null из любого из методов вместо NRE мы получили null в x?

    class Program
    {
        static void Main(string[] args)
        {
            TestV1();
            TestV2();
        }

        static A Method1()
        {
            return null;
        }
        static IOptionalValue<A> TestV1()
        {
            return from x1 in Method1().ToOptionalValue()
                   from x2 in x1.Method2().ToOptionalValue()
                   from x3 in x2.Method3().ToOptionalValue()
                   select x3.Method4();
        }
        static IOptionalValue<A> TestV2()
        {
            return Method1().ToOptionalValue().SelectMany(x1 =>
                x1.Method2().ToOptionalValue().SelectMany(x2 =>
                x2.Method3().ToOptionalValue().SelectMany(x3 =>
                x3.Method4().ToOptionalValue())));
        }
    }

    class A {}

    static class AExtensions
    {
        public static A Method2(this A a)
        {
            return a;
        }
        public static A Method3(this A a)
        {
            return a;
        }
        public static A Method4(this A a)
        {
            return a;
        }
    }

Я лишь показал. Не настаиваю на том что это понятнее.

Впрочем, я уверен, что Sinclair-то знает о чем речь!

	От:	Alexander Polyakov
	Дата:	10.09.10 13:36
	Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	10.09.10 13:44
Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	10.09.10 13:46
Оценка:

	От:	Alexander Polyakov
	Дата:	10.09.10 13:53
	Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	10.09.10 13:55
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	10.09.10 15:17
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	10.09.10 17:39
Оценка: