U>Непонятно в чем заключается выигрыш, при том что огромный проигрыш очевиден.
Выигрыш в том, что следование протоколу статически контролируется компилятором.
U>От проблемы с вызовом Open можно легко избавиться и так, делая его в конструкторе. Проблему с невызовом Close или вызовом его в не тот момент это код никак не помогает решить. От Close в принципе тоже можно избавиться, заменив на Finalize.
Это был лишь пример, достаточно простой.
U>Так бы я сказал, что проблемы с последовательностью вызовов методов это обычно архитектурная проблема, и, как правило, задачу можно решить так, что таких проблем не возникает.
То есть всегда можно сделать интерфейс такой, что бы в нем не было ограничений на последовательность вызовов?
Здравствуйте, 0x7be, Вы писали:
0>То есть всегда можно сделать интерфейс такой, что бы в нем не было ограничений на последовательность вызовов?
Такой интерфейс нельзя сделать, если задача сформулирована как последовательность жестко заданных шагов, причем результат каждого шага необходимо обрабатывать специальным образом. В этом случае, да, введение дополнительных абстракций в виде нового типа на каждый шаг может являться наилучшим решением.
0>Это был лишь пример, достаточно простой.
Это был плохой пример, т.к. в нем нет последовательности шагов. В нем есть инициализация, произвольная работа, завершение, а такие задачи даже сегодняшний шарп позволяет решать почти замечательно.
0>Выигрыш в том, что следование протоколу статически контролируется компилятором.
По сути ты предлагаешь ввести в язык возможность помечать, что вызов данного метода приводит к разрушению объекта, что позволило бы компилятору контролировать, что после разрушения объекта обращений к нему не производится. Идея выглядит разумной, но проблема в том, что определить порядок вызова методов компилятор худо-бедно может только для локальных переменных, да и там по всей видимости не всегда. Соответственно область применения такой фичи окажется слишком узкой.
Практического смысла нет никакого. Да, на примере File/Socket/Stream это красиво выглядит. А если я делаю наследника Socket и хочу наложить ограничение нельзя Read до первого Write? А когда логика начнёт зависеть от передаваемых данных, тогда что делать? Очень узкая предметная ниша и сомнительные бонусы.
В .Net есть IDisposable/ObjectDisposedException. Ну можно ещё упомянуть InvalidOperationException. То есть возможность принципиальная есть, а вот является ли система типов хорошим способом задавать допустимые состояния? Вы фактически хотите системой типой задать НКА. Это ИМХО ужасная идея.
Здравствуйте, adontz, Вы писали:
A>Практического смысла нет никакого.
Не говори гоп...
A>Да, на примере File/Socket/Stream это красиво выглядит.
Хм. Тебе не кажется, что это заявление противоречит предыдущему?
A>А если я делаю наследника Socket и хочу наложить ограничение нельзя Read до первого Write? А когда логика начнёт зависеть от передаваемых данных, тогда что делать?
A>Это как-то относится к типам хоть одного мейнстримового языка? АФАИК даже Немерле так не может.
Это вообще-то код на клоне С#.
Что касается немерле, то именно так как показано по ссылке немерл таки может. Придется допилить напильником инфраструктуру для обработки сообщений и их декларации, но в общем это вполне возможно.
Кроме того так умеют такие языки как Скала и Эрланг. Они оба не мэйнстрим. Но все же уже кое-что, не правда ли?
Ну, а уникальные типы... Если от них будет виден профит, то почему бы не прикрутить. Возможно это не так уж и сложно. Пока что, как я понимаю, нужно всего лишь пометить тип некоторым образом и во время компиляции проверять, чтобы на объект этого типа не было лишних ссылок.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Это как-то относится к типам хоть одного мейнстримового языка? АФАИК даже Немерле так не может. VD>Это вообще-то код на клоне С#.
Там от C# одно название.
VD>Кроме того так умеют такие языки как Скала и Эрланг. Они оба не мэйнстрим. Но все же уже кое-что, не правда ли?
Ну erlang вообще довольно таки особенный язык. и ИМХО эрланг околомейнстримен.
VD>Ну, а уникальные типы... Если от них будет виден профит, то почему бы не прикрутить.
Вот я глубоко уверен, что это просто интересная фенечка, а вот использовать в продакшене это никто по своей воле не будет.
Здравствуйте, adontz, Вы писали:
A>Там от C# одно название.
Отнюдь. Это C# с очень незначительными изменениями. Изучить их можно за пол часа.
VD>>Кроме того так умеют такие языки как Скала и Эрланг. Они оба не мэйнстрим. Но все же уже кое-что, не правда ли?
A>Ну erlang вообще довольно таки особенный язык. и ИМХО эрланг околомейнстримен.
Ну, вот видишь? Значит не все так печально.
VD>>Ну, а уникальные типы... Если от них будет виден профит, то почему бы не прикрутить.
A>Вот я глубоко уверен, что это просто интересная фенечка, а вот использовать в продакшене это никто по своей воле не будет.
Ты судишь на основании своих предрассудков. Я вот ничего сказать не могу. Нужно глубокое изучение вопроса.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
0>Имея первый интерфейс программист физически не может вызвать "не те функции" до вызова Open. Впрочем, он может вызвать 0>Read/Write после Close, что тоже есть нарушение протокола.
Здравствуйте, VladD2, Вы писали:
VD>Я правильно понимаю, что эту хрень можно использовать вместо монад для виртуального превращения императивного кода в функциональный?
Можно. Используют.
В статье даже упоминаются два языка, где этим занимаются.
VD>И что нужно менять в системе типов чтобы получить такие типы? Можно ли их навернуть на базе дотнетной системы типов?
Можно. Примерно как варианты. Те их не поймет никто кроме тех языков, которые им обучены.
Все что нужно это сделать так чтобы после чтения объекта переменная, в которой этот объект лежит, становилась недоступной.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Ну, а уникальные типы... Если от них будет виден профит, то почему бы не прикрутить. Возможно это не так уж и сложно. Пока что, как я понимаю, нужно всего лишь пометить тип некоторым образом и во время компиляции проверять, чтобы на объект этого типа не было лишних ссылок.
Профит от них есть.
Причем даже в императивных языках.
Одно из следствий уникальности это знание о том где умрет последняя ссылка на объект.
А это позволяет сделать детерминированную финализацию.
Таким образом костыли типа using становятся не нужны.
Те если File.Open вернет уникальный тип то можно удет писать так
{
def file = File.Open(...);
def n = file.Read(...);//В данном случае это сахар к такому коду
def (file, n) = Read(file, ...);//Read съедает file и возвращает новый file.
...
}//А тут file будет гарантированно закрыт.
Особо приятно то что такие объекты можно свободно передавать и возвращать из функции имея гарантии того что объект будет разрушен.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Ну, а уникальные типы... Если от них будет виден профит, то почему бы не прикрутить. Возможно это не так уж и сложно. Пока что, как я понимаю, нужно всего лишь пометить тип некоторым образом и во время компиляции проверять, чтобы на объект этого типа не было лишних ссылок.
Здравствуйте, adontz, Вы писали:
A>Предрассудки тут не при чём. Я оцениваю ресурсы необоходимые на изучение, понимание, привыкание и потенциальный выигрыш.
В прикладном приложении выигрыша может и не быть. А вот если речь идёт о повторно используемой библиотеке, то одноразовый гимор разработчика библиотеки с прописыванием автомата состояний в систему типов может обернуться многократным выигрышем для пользователей библиотеки, которых компилятор будет чуть что бить по рукам. Ну и понятно, что далеко не каждый автомат имеет смысл так кодировать, и далеко не каждый функционал вообще содержит этот самый автомат. Тем не менее, фича выглядит весьма красивой, а значит буду поглядывать по сторонам в поисках, куда бы себе её приткнуть.
Здравствуйте, adontz, Вы писали:
A>Предрассудки тут не при чём. Я оцениваю ресурсы необоходимые на изучение, понимание, привыкание и потенциальный выигрыш.
Ты не можешь оценить потенциальный выигрышь пока не опробуешь фичу на практике. Твоя "колоколня" очень субъективна.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Предрассудки тут не при чём. Я оцениваю ресурсы необоходимые на изучение, понимание, привыкание и потенциальный выигрыш. VD>Ты не можешь оценить потенциальный выигрышь пока не опробуешь фичу на практике. Твоя "колоколня" очень субъективна.
Ты абсолютно не прав. Я легко и просто могу оценить потенциальный выигрыш, просто зная количество stateful объектов.
WH> def n = file.Read(...);//В данном случае это сахар к такому коду
WH> def (file, n) = Read(file, ...);//Read съедает file и возвращает новый file.
WH> ...
WH>
неудобно. Тогда нужно вводить правило по котому для уникальных объектов операция доступа к члену (x.y) схожа с передачей "х" по ссылке (y(ref x)). Тогда код будет выглядить привычно, а цель достигаться.
Правда автоматическое закрытие файла можно сделать и проще. Если программист знает, что объект должен быть закрыт до выхода из области видимости, то достаточно конструкции типа use из F# или того же using-а. Так что профит не велик, если говорить только о закрытии файла.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>неудобно. Тогда нужно вводить правило по котому для уникальных объектов операция доступа к члену (x.y) схожа с передачей "х" по ссылке (y(ref x)). Тогда код будет выглядить привычно, а цель достигаться.
А ты читать то что я пишу не пробовал? Ну так для разнообразия?
VD>Правда автоматическое закрытие файла можно сделать и проще. Если программист знает, что объект должен быть закрыт до выхода из области видимости, то достаточно конструкции типа use из F# или того же using-а. Так что профит не велик, если говорить только о закрытии файла.
Профит номер раз: using забыть можно. А тут не забудешь.
Профит номер два: Можно безопасно передавать и возвращать из функции.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
