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

WH>Тебе не надоело позориться?

Тебя позорить не надоело.
Ты сам вызвался очередной вот этой безапелляционностью над безобидными вещами.


WH>Опять же бред написал.

Потому что ты нихрена не понимаешь собеседника опять, как тогда с зависимыми типами. ))


V>>Ну, для ссылочных типов такую же семантику умудрились сделать без накручивания вложенностей определений.
V>>Просто есть специальное значение, приводимое (сравнимое) с произвольным типом — null.
WH>Это аналог Optional<T>.

Аналог, именно.
Одно "но" — значение null не надо многократно "оборачивать" для удовлетворения системы типов.


WH>У Optional<Optional<T>> ДВА различных null'а. У Optional<Optional<Optional<T>>> три.

В этом и проблема.
Потому что value type.
Я именно поэтому напомнил тебе как устроены подобные типы в ФП.


V>>Для алг. типов данных — тоже. Правда, эти типы данных всегда обрабатываются как ссылочные, даже если не ссылочные. ))
WH>Бред.

Аксиома. Попался на незнании.

В Хаскеле значения (Just a) и Nothing — исключительно ссылочные, имеют тип Maybe a (с точностью до "ссылочности").

Итого, точный аналог хаскелевского Maybe в дотнете можно было бы сделать так:

public class Optional<T> where T : struct {
    public readonly T Value;
    public Optional(T value) { Value = value };

    public static Optional<T> Nothing;
}

public static OptionalExtentions {
    public static bool HasValue<T>(this Optional<T> o) where T : struct {
        return o != Nothing;
    }
}

Где некая специальная ссылка (или просто null) означала бы Nothing.

Да, я в курсе про рассуждения насчет эффективности, но она зависит от конкретных сценариев. Когда у нас чаще всего получается Nothing и размер исходной структуры заметен, то "боксированный" вариант эффективней гораздо, бо просто передаётся null. А где Nothing случается нечасто, там заведомо Maybe не особо подходящ.


V>>Если string — это ссылочный тип, то Option<string> не имеет смысла, можно пользоваться сразу string.
WH>Не во всех языках есть null. Ибо null зло.

Почему null зло? Это аналог Optional/Maybe? Разве они зло? ))

Ну ОК, согласен, "строгая" ссылка тоже нужна:

public struct Strong<T> where T : class {
    public readonly T Value;

    public Strong(T value) {
        if(Object.ReferenceEquals(value, null))
            throw ...
        Value = value;
    }
}

Передавай затем "строгую" ссылку прямо как в Хаскеле и будешь всегда уверен, что там Just.

Тут рассуждения простые — если изкаробки у нас уже есть аналог Optional/Maybe для ref-типов, то достаточно ввести обратное — строгий value-тип-обертку для ссылочных.

А если value-типы уже являются "строгими", то для них достаточно ввести ссылочную обертку Optional.


V>>Это всё рассуждения в пользу бедных, потому что прикладная семантика может быть обслужена сугубо прикладными же полями, а не "системными". И даже должна, потому что булевских флагов, связанных со значениям, может быть более одного.
WH>Опять чистейший бред.

Это ты опять не в состоянии распарсить элементарщину. ))
Прикладные вещи должны обслуживаться прикладными полями.
Что тут не понятного?

Какой прикладной смысл хранить в хеш-таблице "нестрогую" ссылку?
Как признак того, что данный ключ "свободен"? Дык, для ровно того же достаточно вообще удалить данный ключ из таблицы.
А за вот эти Optional<Optional<Optional<>>> надо отлучать от программирования пожизненно.
Не в состоянии сформулировать прикладную проблематику — свободен.


WH>>>то без этой фичи код не будет знать есть элемент или в таблице лежит None.
V>>А в общем случае достаточно интерпретировать null как "нет значения".
WH>Не достаточно.
...
WH>Если сюда засунуть тяжёлую функцию (а CachedFactory именно для таких функций и нужно) которая возвращает Option<что-что> то в твоём варианте алгоритм не сможет определить была вызвана функция или нет.

Я же говорю, отлучать за такое от программирования.

У тебя есть простейшая прикладная проблематика — "ленивый" вызов некоей тяжеловесной ф-ии.
Оформь эту прикладную проблематику явным образом по-месту или напиши один раз проблемно-ориентированный Lazy-хелпер и будет тебе счастье.

Кароч, еще не дочитав до сюда я уже знал, в чем дело:

Не в состоянии сформулировать прикладную проблематику — свободен.

Как грится, в хорошем вопросе — половина ответа.

Но ты ставишь вопросы ОЧЕНЬ плохо. Просто отвратительно.
Это твой фирменный стиль, однако — неумение сформулировать проблему.
У тебя вообще с формулировками кошмар (по обсуждениям прошлых лет).
Наверно именно поэтому ты не тянешь большие информационные ёмкости — мы это уже проходили с тобой.
И сейчас ты показал, почему именно.

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

WH>Тебе не надоело позориться?

Тебя позорить не надоело.
Ты сам вызвался очередной вот этой безапелляционностью над безобидными вещами.


WH>Опять же бред написал.

Потому что ты нихрена не понимаешь собеседника опять, как тогда с зависимыми типами. ))


V>>Ну, для ссылочных типов такую же семантику умудрились сделать без накручивания вложенностей определений.
V>>Просто есть специальное значение, приводимое (сравнимое) с произвольным типом — null.
WH>Это аналог Optional<T>.

Аналог, именно.
Одно "но" — значение null не надо многократно "оборачивать" для удовлетворения системы типов.


WH>У Optional<Optional<T>> ДВА различных null'а. У Optional<Optional<Optional<T>>> три.

В этом и проблема.
Потому что value type.
Я именно поэтому напомнил тебе как устроены подобные типы в ФП.


V>>Для алг. типов данных — тоже. Правда, эти типы данных всегда обрабатываются как ссылочные, даже если не ссылочные. ))
WH>Бред.

Аксиома. Попался на незнании.

В Хаскеле значения (Just a) и Nothing — исключительно ссылочные, имеют тип Maybe a (с точностью до "ссылочности").

Итого, точный аналог хаскелевского Maybe в дотнете можно было бы сделать так:

public class Optional<T> where T : struct {
    public readonly T Value;
    public Optional(T value) { Value = value };

    public static Optional<T> Nothing;
}

public static OptionalExtentions {
    public static bool HasValue<T>(this Optional<T> o) where T : struct {
        return o != Nothing;
    }
}

Где некая специальная ссылка (или просто null) означала бы Nothing.

Да, я в курсе про рассуждения насчет эффективности, но она зависит от конкретных сценариев. Когда у нас чаще всего получается Nothing и размер исходной структуры заметен, то "боксированный" вариант эффективней гораздо, бо просто передаётся null. А где Nothing случается нечасто, там заведомо Maybe не особо подходящ.


V>>Если string — это ссылочный тип, то Option<string> не имеет смысла, можно пользоваться сразу string.
WH>Не во всех языках есть null. Ибо null зло.

Почему null зло? Это аналог Optional/Maybe? Разве они зло? ))

Ну ОК, согласен, "строгая" ссылка тоже нужна:

public struct Strong<T> where T : class {
    public readonly T Value;

    public Strong(T value) {
        if(Object.ReferenceEquals(value, null))
            throw ...
        Value = value;
    }
}

Передавай затем "строгую" ссылку прямо как в Хаскеле и будешь всегда уверен, что там Just.
(одно хреново — в дотнете нельзя запретить дефолтный конструктор... зато в С++ можно, считай, что здесь лишь продемонстрировал идею)

Тут рассуждения простые — если изкаробки у нас уже есть аналог Optional/Maybe для ref-типов, то достаточно ввести обратное — строгий value-тип-обертку для ссылочных.

По аналогии, если value-типы уже являются "строгими", то для них достаточно ввести ссылочную обертку Optional.


V>>Это всё рассуждения в пользу бедных, потому что прикладная семантика может быть обслужена сугубо прикладными же полями, а не "системными". И даже должна, потому что булевских флагов, связанных со значениям, может быть более одного.
WH>Опять чистейший бред.

Какой прикладной смысл хранить в хеш-таблице "нестрогую" ссылку?
Как признак того, что данный ключ "свободен"? Дык, для ровно того же достаточно вообще удалить данный ключ из таблицы.

А за вот эти Optional<Optional<Optional<>>> надо отлучать от программирования пожизненно.
Не в состоянии сформулировать прикладную проблематику — свободен.


WH>>>то без этой фичи код не будет знать есть элемент или в таблице лежит None.
V>>А в общем случае достаточно интерпретировать null как "нет значения".
WH>Не достаточно.
...
WH>Если сюда засунуть тяжёлую функцию (а CachedFactory именно для таких функций и нужно) которая возвращает Option<что-что> то в твоём варианте алгоритм не сможет определить была вызвана функция или нет.

Я же говорю, отлучать за такое от программирования.

У тебя есть простейшая прикладная проблематика — "ленивый" вызов некоей тяжеловесной ф-ии.
Оформь эту прикладную проблематику явным образом по-месту или напиши один раз проблемно-ориентированный Lazy-хелпер (который так и будет называться и читаемость кода вырастет на порядки) и будет тебе счастье.

Кароч, еще не дочитав до сюда я уже знал, в чем дело:

Не в состоянии сформулировать прикладную проблематику — свободен.

Как грится, в хорошем вопросе — половина ответа.
Но ты ставишь вопросы ОЧЕНЬ плохо. Просто отвратительно.
Это твой фирменный стиль, однако — неумение сформулировать проблему.
Наверно именно поэтому ты не тянешь большие информационные ёмкости — мы это уже проходили с тобой.
И сейчас ты показал, почему именно.