Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 13.04.11 18:07
Оценка: 14 (4)
В современных мэйнстримовых языках интерфейс представляет собой набор функций (сигнатур), которые комонент должен реализовывать. Однако контракт компонента часто подразумевает нечто большее чем просто номенклатура возможных вызовов (ну или сообщений, так тоже можно сказать). В частности, компоненты могут иметь протокол, то есть легальные последовательности вызовов.

Самый простой пример:
interface ISomething
{
  void Open(...);

  void Read(...);
  void Write(...);
 
  void Close(...);
}

Хотя интерфейс позволяет вызывать методы в любом порядке, здесь первым вызовом необходимо делать Open, последним Close, а остальные между ними. К сожалению, протокол тут выражен лишь в комментариях со всеми недостатками такого подхода.
Можно ли выразить протокол в коде с имеющимися средствами языка C#?

Да, есть некоторые варианты. Например, разбить этот интерфейс на два:

interface ISomethingProvider
{
  ISomethingOperator Open(...);
}

interface ISomethingOperator
{
  void Read(...);
  void Write(...);
 
  void Close(...);
}

Имея первый интерфейс программист физически не может вызвать "не те функции" до вызова Open. Впрочем, он может вызвать
Read/Write после Close, что тоже есть нарушение протокола. Более радикальный вариант переработки имеет следующий вариант:
interface ISomethingProvider
{
  ISomethingOperator Open(...);
}

interface ISomethingOperator
{
  ISomethingOperator Read(...);
  ISomethingOperator Write(...);
 
  void Close(...);
}

Причем, у каждого экземпляра интерфейса можно вызвать только один метод один раз, то есть каждая следующая операция должна совершаться с экземпляром интерфейса, возвращенном из предыдущей операции. Операция Close не возвращает интерфейса, следовательно после нее ничего вызвать нельзя.

Фактически это означает, что интерфейсы должны быть линейными типами, то есть допускать лишь одно использование. C# не позволяет наложить такое ограничение на тип, но его можно контролировать в run-time, бросая исключение. Методы, в зависимости от исхода своей работы, могут возвращать разные интерфейсы, пуская пользовательский код по разным путям в графе состояний протокола. Здесь бы очень пригодились алгебраические типы и pattern-matching, которого в C# тоже нет, но кое-что из палок и веревок соорудить тоже можно

В каком-то смысле этот подход — это доведение принципа ISP до крайности, включающей выделение интерфейса не только для отдельного клиента компонента, но и для отдельного протокольного состояния.

В чем преимущество такого подхода? Протокол становится выражен в коде и статически контролируется компилятором. Программист во многом лишается возможности его нарушить из-за небрежности. Что, пожалуй, ещё важнее, изменение такого протокола приведет к поломке собираемости кода, протокол нарушающего, что очень важно при поддержке большого проекта. Можно сказать, что это будет отловлено и юнит-тестами. Но тесты — это, так сказать, экспериментальная проверка на конечном множестве прецедентов, а такое формальное выражение протокола даст возможность через систему типов статически доказать , что протокол соблюден.

Недостаток подхода очевиден: усложнение интерфейса компонента, растаскивание его функциональности по множеству интерфейсов, усложнение реализации, возможно некоторый overhead во время исполнения, усложнение пользовательского кода.

Предлагаю обсудить эту идею и её жизнеспособность в реальных проектах.
Re[15]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 18.04.11 02:03
Оценка: 2 (1) +1 :)
Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Ну и зря он мне сообщает об ошибке. Дело в том, что при bool==false файл уже открыт, так как раньше (в совсем другом месте) пришлось выполнить предварительное чтение, а поэтому я решил, что не стоит файл закрывать, ибо знаю, что основное чтение делать вскоре придется — незачем тратить время на его закрытие и открытие заново.

0>Предлагаю на будущее сразу формулировать условие задачи целиком, что бы таких роялей в кустах не появлялось. Намного облегчит общение.

0>Касаемо новых условий примера, вот решение:


<skipped>

В том-то и дело, что этот рояль в кустах по ходу разработки появился как черт из табакерки. Не планировал я вначале никакого предварительного чтения, а потом вдруг выяснилось, что оно необходимо. Ты исправил решение на его слуай, а завтра что-то еще изменится. Без этих контрактов вставлю я дополнительные Open, Read, Close и проверю в рантайме тестами работу. А тебе придется на каждый случай модифицировать многое.

Почитай ветвь дискуссии мою с jazzer. То, что ты предлагаешь — это перенос части рантайма в компиле-тайм. Но рантайм гибок, а компиле-тайм — намного меньше, просто потому, что там динамика, а здесь статика. И чем сложнее алгоритм, тем сложнее будет перенести, тем массивнее будут правила в статике, вплоть до полного переноса всей динамики в статику — во всех возможных вариантах.
With best regards
Pavel Dvorkin
Re: Интерфейс vs. протокол.
От: Sorc17 Россия  
Дата: 13.04.11 21:10
Оценка: +1 -2
Я понимаю о чём вы говорите, очень интересная тема. Но пример у вас совсем не показательный ...

... в read()/write() обычно передаётся дескриптор, который создаётся с помощью open(), поэтому вызвать их перед вызовом open() значит передать им не верный дескриптор, а то что дескриптор может быть не верным это нормально: он может испортится и между вызовами read() и write(), так что они "обязаны" прореагировать не неправильный дескриптор. То есть неправильно вызвать read()/write() это значит вообще не понимать данного интерфейса, ни зачем он, ни что делает, ни даже определение функций посмотреть. Программу же не слепоглухонемой пишет, да? close() вы никак не заставите вызвать программиста, потому что нет заранее известного момента когда его нужно вызывать: может быть после последнего read()/write(), а может быть при завершении работы программы, а может быть никогда (операционная система сама закроет все дескрипторы при завершении программы).

Как вариант можно спрятать open() и close() внутрь read() и write(). Например как в функциях PHP: file_get_contents() и file_put_contents().

Полчаса лазал по http://download.oracle.com/javase/6/docs/api/overview-tree.html в поисках наиболее наглядного примера, но устал и бросил, простите.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 15.04.11 13:43
Оценка: 15 (2)
Здравствуйте, 0x7be, Вы писали:

0>В современных мэйнстримовых языках интерфейс представляет собой набор функций (сигнатур), которые комонент должен реализовывать. Однако контракт компонента часто подразумевает нечто большее чем просто номенклатура возможных вызовов (ну или сообщений, так тоже можно сказать). В частности, компоненты могут иметь протокол, то есть легальные последовательности вызовов.


Фактически ты предлагаешь сделать объекты явными конечными автоматами, где состояние автомата будет информацией времени компиляции (т.е. каждый шаг программы будет отражен в типе чего-нибудь — либо самого объекта, либо чего-то связанного).

Если сам объект — мы, имхо, входим на территорию монад и зависимых типов.

Если внешнее, то можно чего-то добиться уже сейчас, хоть это и криво и косо, но можно "из палок и веревок" (я буду юзать C++ как вполне себе мейнстримовый язык).
(плюсофобам дальше не смотреть, я знаю, что в других языках есть разные средства, заранее спасибо)
  Скрытый текст
Т.е. у тебя есть 3 состояния: Initial, Opened, Closed:
struct Initial {};
struct Opened  { std::string fname; }; // можно добавить параметров
struct Closed  {};

события Open, Read, Write, Close (с какими-то параметрами):
struct Open  { string fname; };
struct Read  { string& data_to_read; }; // по ссылке - для считанных данных
struct Write { string data_to_write; };
struct Close {};

и таблица разрешенных переходов, которая, собственно, и составляет наш интерфейс, где следующее состояние — то, что функция возвращает:
struct File
{
  fstream f;
  //          FROM     EVENT  TO      BODY (можно юзать from, ev, to)
  TRANSITION( Initial, Open , Opened, f.open(ev.fname.c_str()))
  TRANSITION( Opened , Read , Opened, f >> ev.data_to_read    )
  TRANSITION( Opened , Write, Opened, f << ev.data_to_write   )
  TRANSITION( Opened , Close, Closed, { f.close(); }          )
};

где TRANSITION — такой вот макрос (to вынесено явно, чтоб можно было его поменять в теле обработчика сообщения):
#define TRANSITION(FROM,EVENT,TO,...) \
  TO go(FROM from, const EVENT& ev) { TO to; __VA_ARGS__; return to; }

В принципе, это более-менее стандартная нотация для конечного автомата, лишь с той разницей, что состояние возвращается наружу, так как мы хотим иметь каждый раз новый тип, и сделать это внутри объекта не удастся.
Юзать надо примерно так (auto и инициализация фигурными скобочками — это из С++0x):
  std::string data_to_read( "new data" );
  File f;
  auto s0 = Initial();
  auto s1 = f.go( s0, Open{"asd0.zip"}   );
  auto s2 = f.go( s1, Write{"data0"}     );
  auto s3 = f.go( s2, Read{data_to_read} );
  auto s4 = f.go( s3, Close()            );

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

Если же нужна просто цепочка вызовов, и мы не хотим писать так:
f.go( f.go( f.go( f.go(
  Initial(), Open{"asd1.zip"} ), Write{"data1"} ), Read{data_to_read} ), Close()
);

то можно написать функцию, которая принимает кортеж событий, и статически проверяет его на валидность (decltype тоже из С++0x, возвращает тип выражения):
#define RET(...) -> decltype( __VA_ARGS__ ) { return __VA_ARGS__; }

// функтор для File::go (в С++0х нет шаблонных лямбд)
struct Go
{
  File& f;
  template< class InitState, class Event >
  auto operator()( InitState s, const Event& ev ) -> RET( f.go(s,ev) )
};

// функция для применения кортежа событий
template< class InitState, class EvSeq >
auto go_chain( File& f, InitState init_state, const EvSeq& t )
  -> RET( fold( t, init_state, Go{f} ))

Юзаем:
auto final_state = go_chain( f, Initial(), make_tuple(
  Open{"asd2.zip"}, Write{"data2"}, Read{data_to_read}, Close()
));

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

Кому интересно и кто хочет поиграться, могу выложить полный код — все компилируется и работает, gcc 4.4.4 -std=gnu++0x.

ЗЫ Конечно же, это игрушечный пример, тут даже ошибки не обрабатываются Обработка ошибок потребовала бы создания чего-то вроде монады Maybe.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[13]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 15.04.11 17:53
Оценка: 2 (1) +1
Здравствуйте, WolfHound, Вы писали:

A>>С какой стати тут ДКА? Прос Open можно вызвать Read или Write. Close можно вызвать после Open, Read или Write. Любой НКА можно свести к ДКА, но обсуждаемая предметная область это именно НКА.

WH>Полный звиздец.
WH>Про автоматы ты вообще ничего не знаешь.
WH>Read и Write это не состояния. Это сообщения.

Давай без перехода на личности, тем более что ты не прав. Есть состояния CanExecute{X}. Изначально автомат в состоянии CanExecuteOpen. Потом он переходит сразу в три состояния (НКА, однако): CanExecuteRead, CanExecuteWrite, CanExecuteClose. Ну и т.д. Причём переход между состояниями может определяться не только типом сообщения, но и его содержимым, так что метод либо невозможно будет применить, либо он искуственно породит кучу лишних типов.

A>>Это всё работает потому что примитивно. Заставь его учитывать приоритеты операций, скобки и сразу поплохеет.

WH>Ни НКА ни ДКА не может распознать рекурсивную структуру.
WH>Это азы.

Хорошо, что ты только что сам признался, что описанный метод не подходит для решения реальных задач. Я это с самого начала и говорил.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 14.04.11 13:53
Оценка: +2
Здравствуйте, 0x7be, Вы писали:

Практического смысла нет никакого. Да, на примере File/Socket/Stream это красиво выглядит. А если я делаю наследника Socket и хочу наложить ограничение нельзя Read до первого Write? А когда логика начнёт зависеть от передаваемых данных, тогда что делать? Очень узкая предметная ниша и сомнительные бонусы.

В .Net есть IDisposable/ObjectDisposedException. Ну можно ещё упомянуть InvalidOperationException. То есть возможность принципиальная есть, а вот является ли система типов хорошим способом задавать допустимые состояния? Вы фактически хотите системой типой задать НКА. Это ИМХО ужасная идея.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[11]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 15.04.11 17:42
Оценка: :))
Здравствуйте, WolfHound, Вы писали:

WH>Кстати то что ты упорно повторяешь НКА тоже кое что говорит о тебе. Ибо тут ДКА. Разница огромна.


С какой стати тут ДКА? Прос Open можно вызвать Read или Write. Close можно вызвать после Open, Read или Write. Любой НКА можно свести к ДКА, но обсуждаемая предметная область это именно НКА.

WH>Вот простой пример:

WH>delete тут конечно лишние но все остальное ты короче ни на чем не напишешь.

Это всё работает потому что примитивно. Заставь его учитывать приоритеты операций, скобки и сразу поплохеет.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[12]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 17:49
Оценка: +2
Здравствуйте, adontz, Вы писали:

A>С какой стати тут ДКА? Прос Open можно вызвать Read или Write. Close можно вызвать после Open, Read или Write. Любой НКА можно свести к ДКА, но обсуждаемая предметная область это именно НКА.

Полный звиздец.
Про автоматы ты вообще ничего не знаешь.
Read и Write это не состояния. Это сообщения.

A>Это всё работает потому что примитивно. Заставь его учитывать приоритеты операций, скобки и сразу поплохеет.

Ни НКА ни ДКА не может распознать рекурсивную структуру.
Это азы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[28]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 18.04.11 04:30
Оценка: +2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А теперь представь себе, что мне нужно по процентам двухкомпонентной смеси любого состава определить точку кипения смеси (эх, если бы это было возможно — нет такого способа расчета). И получишь ты в итоге float[-273..5000], то есть просто float.

Ты либо крестик сними, либо трусы надень.
Если это можно вычислить, то это можно сделать на уровне системы типов.
Если нельзя то, какого черта вообще появилась GetMixtureBoilingPoint?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 17.04.11 14:30
Оценка: 22 (1)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А я и не обвинял. Просто уж так получилось, что он намертво связан с этим провалившимся проектом. То ли он украл, то ли у него украли...




J>>ЗЫ. Мой учитель по вычматам любил говорить, что для большинства интересных численных моделей строгое обоснование модели эквивалентно аналитическому решению самой исходной задачи.


PD>Именно. Можно и другие примеры предложить.


Ну вот. Но это же не значит, что численные методы плохи или что им нет полезных применений
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re: Интерфейс vs. протокол.
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 14.04.11 09:04
Оценка: 6 (1)
Здравствуйте, 0x7be, Вы писали:

0>Фактически это означает, что интерфейсы должны быть линейными типами, то есть допускать лишь одно использование. C# не позволяет наложить такое ограничение на тип, но его можно контролировать в run-time, бросая исключение. Методы, в зависимости от исхода своей работы, могут возвращать разные интерфейсы, пуская пользовательский код по разным путям в графе состояний протокола. Здесь бы очень пригодились алгебраические типы и pattern-matching, которого в C# тоже нет, но кое-что из палок и веревок соорудить тоже можно


Имхо, ближе всего к описанному то, как подобные штуки (например, работа с консолью или файлами) сделаны в языке Clean. Там как раз на уникальных типах это все.
Re[2]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 13.04.11 18:47
Оценка: 4 (1)
Здравствуйте, dimgel, Вы писали:

0>>Фактически это означает, что интерфейсы должны быть линейными типами, то есть допускать лишь одно использование. C# не позволяет наложить такое ограничение на тип

D>А интересно, кто-нибудь может? И как это выглядит? Через систему типов скалы я чёт тоже не могу сообразить. Ссылка на интерфейс должна становиться невалидной после обращения к нему... эт как? Красивая идея, но вот этот момент всё портит.
Такие типы называются Uniqueness type.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Интерфейс vs. протокол.
От: dimgel Россия https://github.com/dimgel
Дата: 15.04.11 07:45
Оценка: 4 (1)
Здравствуйте, adontz, Вы писали:

A>Предрассудки тут не при чём. Я оцениваю ресурсы необоходимые на изучение, понимание, привыкание и потенциальный выигрыш.


В прикладном приложении выигрыша может и не быть. А вот если речь идёт о повторно используемой библиотеке, то одноразовый гимор разработчика библиотеки с прописыванием автомата состояний в систему типов может обернуться многократным выигрышем для пользователей библиотеки, которых компилятор будет чуть что бить по рукам. Ну и понятно, что далеко не каждый автомат имеет смысл так кодировать, и далеко не каждый функционал вообще содержит этот самый автомат. Тем не менее, фича выглядит весьма красивой, а значит буду поглядывать по сторонам в поисках, куда бы себе её приткнуть.
Re[9]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 16.04.11 12:50
Оценка: 4 (1)
Здравствуйте, 0x7be, Вы писали:

0>То есть нет возможности вызвать функцию обработки данных до её загрузки или если загрузка обломалась.

0>И нет возможности вызвать функцию скачки результата, если данные не были обработаны.

А теперь представь себе, что если загрузка обломалась, то надо выполнить операцию восстановления работоспособности сервера (или БД), после чего окажется, что загрузка уже прошла (для БД это странно, конечно, но в других случаях возможно, что некая инициализация обязана не только открыть канал, но и загрузить первую порцию данных).

Или если данные не обработаны, то нельзя скачивать результат, но можно (и нужно!) произвести ренинициализацию БД. Данные неправильно считаны, надо все с начала делать. Опять же с БД маловероятно, а в другом случае может быть.

Понимаешь, в чем проблема. Логика действий , вообще говоря, зависит от того, как выполнены предыдущие действия. Она может быть сколь угодно сложной, и все ее варианты могут быть оценены только путем выполнения и изучения результатов. А ты хочешь каким-то образом без того, чтобы эти результаты получить, сделать вывод о том, правильная ли эта логика (== потребовать от компилятора. чтобы он ее верифицировал).

Разумеется, есть множество алгоритмов или задач, которые допускают такую верификацию. Если логика достаточно проста, иными словами, этих путей исполнения немного (а лучше всего 1), то можно до исполнения определить, верна ли логика. Но в общем случае нет.

Вот тебе простой пример (из какой-то книги, которую я в молодости читал). Алгоритм одевания мужчины. Весь перечислять не буду, но ясно, что носки нужно надеть раньше, чем ботинки, а пиджак позже, чем рубашку. Хотя и тут вариантов много. Можно в таком порядке : носки, рубашку, пиджак , брюки,, ботинки. А можно и в таком порядке — носки, брюки, рубашку, пиджак, ботинки . А впрочем, и так можно, хотя и странно : рубашку, пиджак, брюки, носки, ботинки. Хотя после 3-го этапа выглядеть будешь весьма глупо

Вот и посчитай, сколько тут вариантов, и попробуй оцени без выполнения, правилен ли выбранный. Теоретически возможно. Построить граф всех правильных путей и проверить, есть ли наш путь в этом графе. Но возни тут намного больше, чем если проверить наш алгоритм на коллеге

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

ИМХО все это чистый академизм, не имеющий отношения к реальной работе. Теоретизировать можно, а потом все это уйдет в архив вполне благополучно. Как с Сигуларити. Мне ее WolfHound пару лет назад усиленно пропагандировал, мол, новое слово, ОС на основе управляемого и верифицируемого кода. Новое — да, но и только. А теперь говорят, что ее вовсе закрыли (http://rsdn.ru/forum/life/4229495.1.aspx
Автор: Романов Михаил
Дата: 11.04.11
). Впрочем, если и не закрыли, то все равно толку мало...
With best regards
Pavel Dvorkin
Re: Интерфейс vs. протокол.
От: Sinix  
Дата: 14.04.11 06:17
Оценка: 1 (1)
Здравствуйте, 0x7be, Вы писали:

0>В современных мэйнстримовых языках интерфейс представляет собой набор функций (сигнатур), которые комонент должен реализовывать. Однако контракт компонента часто подразумевает нечто большее чем просто номенклатура возможных вызовов (ну или сообщений, так тоже можно сказать). В частности, компоненты могут иметь протокол, то есть легальные последовательности вызовов.

...

Угу. Идея абсолютно верная.

Я вам не скажу за всю Одессу, но МС активно заигрывает с верифицируемым кодом. Всё идёт к тому, что это станет основной фичей или 6го, или 7го шарпа

Про singularity уже писали, в ту же степь идёт Midori (но там ничего интересного нет) и Verve (а вот про неё почитать стоит).

Если смотреть в сторону мейнстрима, то тут у МС Axum в инкубаторе и Code Contracts в стадии тестирования на мышах.

Осталось прикрутить сахар для continuation passing (хотя оно уже в принципе есть в виде await + RX) — и у нас получается забавный аналог эрланга
Re[38]: Интерфейс vs. протокол.
От: VoidEx  
Дата: 19.04.11 09:51
Оценка: 1 (1)
Здравствуйте, Pavel Dvorkin, Вы писали:

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


VE>>low и high и так на этапе компиляции неизвестны, если ты об этом.


PD>Тогда я не понимаю, как функция может вернуть ограниченный float[low..high]


Тут 22 страницы со ссылками на зависимые типы.
Re[4]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 14.04.11 05:56
Оценка: +1
Здравствуйте, Sorc17, Вы писали:

S>Можно как-то при этом ещё оставить программисту возможность вызывать методы "не правильно"?

Зачем?
Re: Интерфейс vs. протокол.
От: Undying Россия  
Дата: 14.04.11 10:19
Оценка: +1
Здравствуйте, 0x7be, Вы писали:

0>
0>interface ISomethingProvider
0>{
0>  ISomethingOperator Open(...);
0>}

0>interface ISomethingOperator
0>{
0>  ISomethingOperator Read(...);
0>  ISomethingOperator Write(...);
0>  void Close(...);
0>}
0>

0>Причем, у каждого экземпляра интерфейса можно вызвать только один метод один раз, то есть каждая следующая операция должна совершаться с экземпляром интерфейса, возвращенном из предыдущей операции. Операция Close не возвращает интерфейса, следовательно после нее ничего вызвать нельзя.

Непонятно в чем заключается выигрыш, при том что огромный проигрыш очевиден.

От проблемы с вызовом Open можно легко избавиться и так, делая его в конструкторе. Проблему с невызовом Close или вызовом его в не тот момент это код никак не помогает решить. От Close в принципе тоже можно избавиться, заменив на Finalize.

Так бы я сказал, что проблемы с последовательностью вызовов методов это обычно архитектурная проблема, и, как правило, задачу можно решить так, что таких проблем не возникает.
Re[7]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 15.04.11 07:32
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Ты судишь на основании своих предрассудков. Я вот ничего сказать не могу. Нужно глубокое изучение вопроса.


Предрассудки тут не при чём. Я оцениваю ресурсы необоходимые на изучение, понимание, привыкание и потенциальный выигрыш.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[3]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 15.04.11 14:44
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


J>>Фактически ты предлагаешь сделать объекты явными конечными автоматами, где состояние автомата будет информацией времени компиляции (т.е. каждый шаг программы будет отражен в типе чего-нибудь — либо самого объекта, либо чего-то связанного).


VD>Ты путаешь наличие и контроля за состоянием с конечными автоматами. КА — это только один из видов представления и управления состоянием. Обратное не верно. Отличительно особенностью КА является наличие явно описываемых состояний. Здесь этого нет. Это скорее инкапсуляция состояния.


Если честно, не понял, что ты хотел сказать и что из твоих слов должно следовать.
Явно описываемые состояния у 0x7be есть — "можно позвать метод1", "нельзя позвать метод2", и т.д. Что ты понимаешь под инкапсуляцией здесь, я тоже не понял.
В общем, можешь по предложениям развернуть свою мысль?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
от модератора
От: WolfHound  
Дата: 15.04.11 15:57
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

Следи за тем сколько цитируешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 15.04.11 16:34
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Может, я неправильно понял, но я полагал, что под статическим контролем компилятора ты имеешь в виду контроль в дизайн-тайме. А файлы компилируются независимо.

WH>А тебя не удивляет статический контроль за типами функций описанных в разных файлах?

Нет. Это элемент времени компиляции. Если функция требует int, то нечего ей передавать что-то иное. А вот порядок вызова функций — дело не времени компиляции, а именно рантайма.

Усложню и сделаю более абстрактным пример ТС.


interface ISomething
{
   void First(...);
   void Second(...);
   void Third(...);


Представь себе, что первым делом надо вызывать только First. А вот дальше в зависимости от того, что получилось — то ли Second, то ли сразу Third, а может быть, и First еще раз, с другими параметрами. А после Second , может быть, надо вызвать не Third, а опять же First, потому что не получилось, и надо начать все сначала, с иными параметрами. И т.д. Как это контролировать в complile-time , я не понимаю, а главное — не понимаю зачем.
With best regards
Pavel Dvorkin
Re[9]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 15.04.11 17:09
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

PD>>а главное — не понимаю зачем.

WH>Ровно за тем же за чем контролировать чтобы вместо int string не воткнули.

Давай я тебя спущу на землю. Напиши руками (никаких PEG/Antlr/CoCoR) парсер HTML, самый примитивный и с упрощениями. А потом мы поговрим как это круто описывать НКА руками в коде.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[15]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 15.04.11 18:19
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

A>>Давай без перехода на личности, тем более что ты не прав.

WH>Ой Рама... лол.
WH>Я по уши в автоматах. Так шта...

Увы, тебе не удалось произвести на меня впечатления.

A>>Есть состояния CanExecute{X}. Изначально автомат в состоянии CanExecuteOpen. Потом он переходит сразу в три состояния (НКА, однако): CanExecuteRead, CanExecuteWrite, CanExecuteClose. Ну и т.д.

WH>Есть состояние Closed из которого можно вызвать только Open.
WH>Есть состояние Ready из которого можно вызвать Read, Write, Close.
WH>Closed -> Open -> Ready
WH>Ready -> Write -> Ready
WH>Ready -> Read -> Ready
WH>Ready -> Close -> Closed
WH>Вот реальное состояние дел.
WH>И где тут НКА?

Ты "в уме" создал для НКА соответствующий ДКА, а теперь пытаешься меня убедить что так и было? Нет, не выйдет. Давай немножечко усложним задачу. После Open можно вызвать Read или Write, но потом их надо чередовать.
Получим НКА
CanOpen -{Open}-> CanRead,CanWrite,CanClose
CanRead -{Read}-> CanWrite,CanClose
CanWrite -{Write}-> CanRead,CanClose
CanClose -{Close} -> nil (пустое множество)
А вот у ДКА будет уже аж три разных состояния — вариации изначального Ready. Так что не путай предметную область и метод реализации. Конечно же, никто не реализует НКА как есть, это просто медленно, но задаётся здесь именно НКА.

A>>Причём переход между состояниями может определяться не только типом сообщения, но и его содержимым, так что метод либо невозможно будет применить, либо он искуственно породит кучу лишних типов.

WH>Ты пример РЕАЛЬНОГО кода который я тебе показал посмотри.

Посмотрел. Примитивизм, подогнанный под инструмент. Зато я тебе могу дать действительно реальный пример. Реализовываем сетевой протокол (практически любой). Надо прочитать запрос клиента до конца прежде чем ответить. То есть можно ли после очередного Read выполнять Read или Write определяется прочитанными данными. То есть, цитируя себя самого, "переход между состояниями может определяться не только типом сообщения, но и его содержимым". Естественно, описать это на уровне типов не получится.

A>>Хорошо, что ты только что сам признался, что описанный метод не подходит для решения реальных задач. Я это с самого начала и говорил.

WH>Это как "отверткой нельзя забивать гвозди". А ты "Я же говорил что отвертки для реальной работы не подходят.".

Совсем даже не так, потому что гвозди всё же весьма распространены, а КА с фиксированным и малым числом возможных переходов — нет.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[17]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 15.04.11 19:35
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>ЛОЛ! Рома ты мне не поверишь но это просто альтернативный метод записать ДКА


Да, он называется НКА.

WH>Вот это "CanRead,CanWrite,CanClose" состояние.


Если НКА преобразовать в ДКА.

WH>Из него 3 перехода в состояния "CanWrite,CanClose", "CanRead,CanClose" и nil.


A>>Посмотрел. Примитивизм, подогнанный под инструмент. Зато я тебе могу дать действительно реальный пример. Реализовываем сетевой протокол (практически любой). Надо прочитать запрос клиента до конца прежде чем ответить. То есть можно ли после очередного Read выполнять Read или Write определяется прочитанными данными. То есть, цитируя себя самого, "переход между состояниями может определяться не только типом сообщения, но и его содержимым". Естественно, описать это на уровне типов не получится.

WH>Рома ты просто фееричен.
WH>На читай:

"NoMoreData! -> SendOnly;" это твои фантазии, а не парсинг запроса. Если клиент приклал больше чем надо (пайплайнинг) или меньше (лаги, фрагментация) и сейчас данных больше нет, то это не значит что запрос прислали.

A>>Совсем даже не так, потому что гвозди всё же весьма распространены, а КА с фиксированным и малым числом возможных переходов — нет.

WH>Скачай уже исходники сингулярити.

Сингуларити... дай вспомнить.... Веб-сервер в 8 раз медленее на там же железе, 50Мб/с — максимальная пропускная способность TCP/IP стека и твои уверения, что безопасность не влияет на скорость. Нет, не интересно.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[11]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 16.04.11 12:02
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

PD>>Тогда упростим. Я подобный вопрос уже несколько раз задавал. От своего невежества, конечно. Только почему-то никто на него не ответил. Вот давай ответь.

WH>Я тебя уже не первый год тыкаю носом в эту ссылку.
WH>http://en.wikipedia.org/wiki/Dependent_type

Да не в ссылке же дело. В идее о том, что можно предсказать результат без исполнения. Вот это мне и сомнительно.

WH>Вот тебе ссылки про адаптацию этой теории для практики.

WH>http://scholar.google.com/scholar?hl=ru&amp;q=type+refinements+programming&amp;btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&amp;as_ylo=&amp;as_vis=0
WH>Только ты же всеравно учиться не будешь.

PD>>Ну вот я тебе пример привел выше, с минусом и корнем. Объясни просто и понятно, каким образом, не запуская программы, можно проверить правильность порядка вызова функций. Продемонстрируй свои знания в ответ на мое невежество.

WH>Я тебе уже много всякого разного показывал но ты все проигнорировал.
WH>Заниматься твоим образованием мне лень.

То есть ты пополнил список тех, кому я этот вопрос задал и кто ответить так и не смог. Неудивительно.

WH>В рамках C# это не решается. Тут как минимум type refinements нужны, а их в C# нет.


А ТС просил все же C#
With best regards
Pavel Dvorkin
Re[12]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 16.04.11 15:18
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Да не в ссылке же дело. В идее о том, что можно предсказать результат без исполнения. Вот это мне и сомнительно.

По этой ссылке написано как это сделать.

PD>То есть ты пополнил список тех, кому я этот вопрос задал и кто ответить так и не смог. Неудивительно.

Ну разумеется.
Если ответы тупо игнорируются...
Ссылки я тебе дал.
Если есть желание образовывайся.
Если нет, то перестань бравировать своим невежеством. Не смешно уже.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 16.04.11 16:52
Оценка: :)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:

VD>>>То и говорю. Наличие состояния и контроль за ним еще не означает, что это КА.

J>>В общем случае — может быть
VD>А наш случай частный?

В том виде, в котором он сформулирован (набор методов и ограничения на последовательность вызовов) — да.

J>> (хотя математически сам компьютер — это КА, и соответственно все, что на нем работает, тоже КА),


VD>Ой как интересно! С удовольствием послушаю о том какое состояние конечное у компьютера.

В школу. Конечность автомата относится к конечности множества состояний.

VD>А машина Тьюринга или лямбда-исчисления Черча — это тоже КА? Тогда можно за одно рассказать и о конечном состоянии машины Тьюринга.

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

J>> но вот в этом конкретном обсуждаемом случае я вижу КА в чистом и незамутненном виде. Объясни, почему то, о чем говорит 0x7be — это не КА.


VD>Да всем. Нет входных данных, например.

Входные данные — последовательность вызовов в программе.

VD>Да и вообще никаких атрибутов КА.

Правда? ну и какие, по-твоему, атрибуты у КА, что их тут "никаких" нет? Список атрибутов КА с пояснениями, почему их нет тут, очень поможет дальнейшему обсуждению.

VD>Не, безусловно, многие задачи можно описать в том числе и КА. Но и без них тоже можно. При этом КА описывают не все задачи. Например, бесконечные (рекурсивные) или задачи требующие для работы дополнительной памяти (например, парсинг).

Реальные задачи на реальных компьютерах — все. Всегда, когда у тебя возникают различные состояния — у тебя КА. Любой парсер представляет собой КА с по крайней мере четырьмя состояниями "еще не начали", "в процессе", "закончили успешно", "обнаружена ошибка". Сам компьютер — это КА, это медицинский факт.

VD>По сему не надо привязывать сюда КА. Они тут не причем. Вот внутри уникального типа может использоваться КА для обработки логики. Но уникаьные типы сами по себе — это всего лишь контроль за тем, чтобы в один момент времени на объект не было более одной ссылки. А логика у него может быть любой сложности, как укладывающейся в КА, так и не укладывающейся.


Причем тут уникальные типы, если они, как ты правильно отметил, всего лишь гарантируют единственность ссылки? Как они, сами по себе, помогут нам выразить требования?

VD>>>КА — это реализация. А оных может быть много. С монадами знаком?

J>>Знаком. Чем КА-то не угодил, если он укладывается в требования 0x7be?
VD>Тем что ты их за уши притянул. Я с тем же успехом могу притянуть монады. Они тоже позволяют связать вычисления.

Понятно. А если б я все написал на монадах, ты бы сказал, что они не катят, потому что можно описать все то же самое на зависимых типах. И по кругу до КА. Суперская логика.

J>> И КА — это в первую очередь математическая абстракция

VD>Есть много мат.абстракций. И что?
И то, что я могу использовать любую подходящую, если она решает задачу. Я вижу, что КА ее решает. Ты мне пока что даже и намека не дал на то, что КА ее не решает, только пустопорожнее сотрясание воздуха со смехотворными аргументами типа "а еще можно на монадах".

VD>Эта интересна тем, что ты ей уделил больше внимания?

Эй, господин модератор, ты вообще никак не можешь без переходов на личности?

J>>объекта с состоянием и графом разрешенных переходов: http://en.wikipedia.org/wiki/Finite-state_machine. Так что это не КА — реализация, а КА допускает много реализаций.


VD>Где ты переходы то усмотрел? У тебя метод может получить ссылку и она может остаться в нем.

И что? Какое это отношение имеет к состояниям? которые мы хотим ограничить? У тебя какое-то в высшей степени оригинальное понятие о КА. Хотя судя по твоему перлу насчет конечного состояния компьютера, вывод тут только один может быть.

J>>Да ну? А если файл открыть не удалось, много тебе скажут дескриптор и смещение?


VD>Многое. Хэндл будет некорректным (например, равный нулю).

Я про такое использование дескриптора написал в следующем же предложении, ты его вообще прочитал или так отвечаешь, по рэндому?

VD>Меня другое интересно. А что делать, если система типов сложнее чем в случае открытия файлов?


В смысле — что делать? Программить, вестимо. Ну сложнее, и что с того? Значит, и программа получится сложнее

VD>Пойми. Ну, нельзя прописать какую-то сложную логику в типах. Только простой набор связей. Там и вычислений то никаких не будет. Это чистая декларация.


Нам не нужна сложная логика. Нам нужна реализация КА во время компиляции, и только.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[18]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 17.04.11 05:54
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Нет. Мне доказывают, что можно сделать нечто, что позволит определить правильность порядка вызова функций без запуска программы, статически. Я привожу пример, когда ИМХО невозможно без запуска определить, правилен порядок или нет. Вот и все.

Я тебе уже несколько лет привожу ссылки на статьи, где описаны и теория и практика.
Даны все теоремы и их доказательства.
Продемонстрированы работающие компиляторы, которые это делают на практике.
Причем все статьи прошли рецензию и опубликованы в уважаемых изданиях.
Все что нужно сделать, это прочитать статьи с включенным мозгом.
А ты все не возможно да не возможно.
Такое поведение называется воинствующее невежество.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Интерфейс vs. протокол.
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 17.04.11 06:23
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Нет. Мне доказывают, что можно сделать нечто, что позволит определить правильность порядка вызова функций без запуска программы, статически. Я привожу пример, когда ИМХО невозможно без запуска определить, правилен порядок или нет. Вот и все.

WH>Я тебе уже несколько лет привожу ссылки на статьи

Чем повторять все это лучше бы взял и привел пример кода на Agda2 (или другом языке с зависимыми типами) для данной задачи с корнем. Для знающего человека там вряд ли больше нескольких строк.
Re[19]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 10:12
Оценка: +1
Здравствуйте, jazzer, Вы писали:

PD>>Нет. Мне доказывают, что можно сделать нечто, что позволит определить правильность порядка вызова функций без запуска программы, статически. Я привожу пример, когда ИМХО невозможно без запуска определить, правилен порядок или нет. Вот и все.


J>Ну, просто порядок вызовов статически определить не проблема, правильно? См. Boost.Proto, например.

J>Т.е. отталкиваемся от того, что порядок узнать мы можем и проверить его тоже можем (оставим пока за скобками то, что в этом примитивном случае у тебя проверяющий код будет сравним с самим кодом).

Порядок чего ? Вызовов в рантайме ? Проверяющий код будет при этом не сравним с самим кодом, а просто равен ему. И ничего тут не поможет. Вот пример, я его уже приводил


float func(float f)
{
 // итерационный процесс решения некоторого уравнения, для которого f - стартовая точка. Уравнение имеет 2 корня, один >0, другой <0
 if(root>0)
  DoX(root);
 else DoY(root)
}


Можно ли определить, какая функция будет вызвана : DoX или DoY без этого проведения этого итерационного процесса в полном объеме ? Если бы это было возможно, математики человеку, которое такое решение бы предложил, при жизни памятник поставили.

И в моем примере с sqrt вопрос не в том, должен ли быть аргумент sqrt положительным. Вопрос в другом — правильно ли я задал порядок действий. Твое решение того примера см. ниже, а пока модифицирую его


if(x<0)
 y = sin(cos(x));
else
 y = cos(sin(x));


Тут все аргументы годятся , и этот код никаких исключений вызвать не должен. Но правильно ли я его написал ? Может, надо было написать if(x<0) ? И ты берешься в compile-time без тестирования сказать, правильно или нет ?

>Осталось только проверить, правильная ли версия выбирается в зависимости от знака аргумента. Для этого нужно знак вынести в тип (т.е. на выходе if должна быть не просто f, а Positive(f) для главной ветки и NonPositive(f) для ветки else) — это и есть зависимые типы:

J>
J>struct Positive { float f; };
J>struct NonPositive { float f; };
J>// и т.д. для Negative, Zero и т.д.

J>Positive sqrt(Positive);
J>NonPositive minus(Positive);
J>Positive minus(NonPositive);
J>

J>Здесь видно, что и minus(sqrt(Positive)), и minus(sqrt(minus(NonPositive))) даст NonPositive, а sqrt(NonPositive) просто не скомпилируется.

J>Управляющие структуры обычный С++ нетипизированы (в том смысле, как я написал выше). Поэтому придется написать свой if как-то так:

J>
J>template <class Then, class Else>
J>void if_positive(float f, Then then_, Else else_)
J>{
J>  if (f>0) then_( Positive(f) ); else_( NonPositive(f) );
J>};
J>

J>как видишь, теперь у нас рантайм-свойство переменной (знак) выражено в типе, и когда ты будешь звать if_positive и попробуешь передать ему sqrt в качестве else — программа не скомпилируется.


J>Идея понятна?


Идея-то , конечно, понятна, и ее можно изложить двумя словами, без всяких примеров — размножить типы в зависимости от возможных значений и сыграть на несовместимости типов разных структур. Этот фокус известен давно. Ты с Win API, наверное, знаком ? Там есть хендлы, по существу — целые числа, а реализованы как указатели на пустые структуры, для каждого типа хендла — свой тип структуры. Поэтому вот такое

HPEN hPen = ...
HBRUSH hBrush = hPen;

не пройдет при компиляции.

Но применимость такой идеи ничтожна, и по сути ограничивается именно таким примером, ну может, еще парочкой иных. А в том же примере с sqrt и положительными- неотрицательными и т.д. стоит лишь слегка его усложнить (например, разделить все множество не на 2 (положительные и неположительные), а, скажем, на 10-20 интервалов- и сразу вся эта затея превратится в необозримое чудовище. А если таких чудовищ будет с десяток (а это пустяки), то в этом хаосе уже никто не разберется. Я никак не могу поверить в серьезность подобной затеи.
With best regards
Pavel Dvorkin
Re[22]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 17.04.11 12:11
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

WH>>А ты даже пару небольший статей прочитать не можешь.

PD>Не хочу.
ЧТД.
Ты сюда пришёл не за знаниями, а для того чтобы свою веру отстаивать.

PD>Ну и не трать. Тебя заставляют ? Ты же влез в эту дискуссию и ответил на какое-то мое сообщение, а не я. Мне вообще с тобой дискутировать совсем не интересно.

А я не на тебя время трачу.
Проблема в том, что воинствующий невежда, уверенный в своей правоте может просто передавить нормальных людей с недостатком знаний.
А это уже прямой вред посетителям сайта.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 17.04.11 13:55
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Точнее , для того, чтобы высказывать свою точку зрения, даже если она не совпадает с чьей-то иной или даже лбщепринятой.

О чем я и говорю.
Ты пропагандируешь свою веру.
При этом игнорируя сотни статей в рецинзируемых журналах.

PD>Добродетель, которая нуждается в защите, едва ли стоит того, чтобы ее защищать. (С) не помню чей.

Это бред полнейший.

PD>Какая трогательная забота о посетителях! Ну тогда продолжай ее и дальше.

Обязательно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Интерфейс vs. протокол.
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 17.04.11 20:06
Оценка: +1
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, WolfHound, Вы писали:

WH>>Я же говорю, он сюда свою веру пришёл пропагандировать, а не знания получить.

WH>>Он этой фигней уже не первый год занимается.
0>А в чем его вера заключается?

Народ... Тема не об этом.

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[2]: Интерфейс vs. протокол.
От: vdimas Россия  
Дата: 17.04.11 21:29
Оценка: +1
Здравствуйте, jazzer, Вы писали:

J>Фактически ты предлагаешь сделать объекты явными конечными автоматами, где состояние автомата будет информацией времени компиляции


Да не катят тут объекты никак. Вызов метода объекта не подменяет исходную identity, а требуется именно подменять. Правильно было сказано, что нужен функциональный подход на uniqueness типах. Вполне можно и на С++:
struct Opened  { std::string fname; }; 
struct Closed  {};

Предположим, что у нас есть некий strict_auto_ptr<>, аналог auto_ptr, но без метода release(), чтобы мы могли гарантировать передачу владения.
typedef strict_auto_ptr<Opened> OpenedPtr;
typedef strict_auto_ptr<Closed> ClosedPtr;


Тогда:
OpenedPtr file = openFile("some-path");
file = read(file, &buffer, count);
file = read(file, &buffer2, count2);


От монады maybe можно смело отказываться при наличии нормального механизма исключений. Здесь чтение в buffer2 не покатит, если во время операции чтения в buffer мы не сохранили file, ведь при передаче параметра в read() мы потеряли владение ссылкой.

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

Характерно, что на C# подобный фокус воспроизвести не получится.
Re[39]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 19.04.11 10:00
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Тогда я не понимаю, как функция может вернуть ограниченный float[low..high]

WH>Пятисотый раз повторяю: Читай про зависимые типы.

Второй (пока что) раз объясняю — надоел.
With best regards
Pavel Dvorkin
Re[40]: Интерфейс vs. протокол.
От: VoidEx  
Дата: 19.04.11 10:12
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

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


PD>>>Тогда я не понимаю, как функция может вернуть ограниченный float[low..high]


VE>>Тут 22 страницы со ссылками на зависимые типы.


PD>Если можешь объяснить (на пальцах), как это должно компилироваться и работать (пример, который я привел) — объясни. Если нет — закончим дискуссию.


Выберу третье: могу, но не буду. Я считаю, что самостоятельный человек должен уметь сам извлекать информацию. Если не может — он идиот, и не стоит на него тратить время. Если может, но не делает, — значит не хочет, и тоже не стоит тратить на него время. Вот если бы информация была недоступна или чересчур сложна, был бы другой разговор.
Re[41]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 19.04.11 12:07
Оценка: :)
Здравствуйте, VoidEx, Вы писали:

VE>Выберу третье: могу, но не буду. Я считаю, что самостоятельный человек должен уметь сам извлекать информацию. Если не может — он идиот, и не стоит на него тратить время. Если может, но не делает, — значит не хочет, и тоже не стоит тратить на него время. Вот если бы информация была недоступна или чересчур сложна, был бы другой разговор.


Самостоятельный человек , прежде чем выбирать информацию, должен убедиться в том, что она может быть ему полезной. В противном случае он рискует выбрать массу бесполезной информации. Объять необъятное нельзя, а вся информация по ИТ сейчас — море необъятное. Вот для этого форумы и нужны — они позволяют объяснить в нескольких словах самостоятельному человеку, в чем эта информация заключается и почему она может быть полезной. Твое полное право это не делать, но и мое полное право не заниматься изучением всерьез чего-то, в полезности которого у меня большие сомнения. Лучше я что-то другое за это время изучу, такое, что сомнений вызывает меньше или совсем не вызывает.

На этом, как говорили раньше, позвольте откланяться, примите и проч.
With best regards
Pavel Dvorkin
Re: Интерфейс vs. протокол.
От: dimgel Россия https://github.com/dimgel
Дата: 13.04.11 18:22
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Фактически это означает, что интерфейсы должны быть линейными типами, то есть допускать лишь одно использование. C# не позволяет наложить такое ограничение на тип


А интересно, кто-нибудь может? И как это выглядит? Через систему типов скалы я чёт тоже не могу сообразить. Ссылка на интерфейс должна становиться невалидной после обращения к нему... эт как? Красивая идея, но вот этот момент всё портит.
Re[2]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 13.04.11 18:43
Оценка:
Здравствуйте, dimgel, Вы писали:

D>А интересно, кто-нибудь может? И как это выглядит? Через систему типов скалы я чёт тоже не могу сообразить. Ссылка на интерфейс должна становиться невалидной после обращения к нему... эт как? Красивая идея, но вот этот момент всё портит.

C# этого не позволяет статически проконтролировать в принципе. C# позволяет лишь до некоторой степени автоматизировать выбор исключения при повторном вызове метода. Тут нужна либо прямая поддержка линейных типов в языке, либо некоторый code walker (макрос или внешняя программа, как анализирующая код как FxCop), который будет анализировать AST программы и обнаруживать нарушения.

С другой стороны, этот вопрос может решаться административно. Для всех таких "цепных" интерфейсов будет действовать общее правило — не обращаться по одной ссылке более одного раза. Его выполнение можно контролировать на code review.

Так что методы контроля есть, просто они не столь хороши, как прямая поддержка языка.
Re: Интерфейс vs. протокол.
От: WolfHound  
Дата: 13.04.11 18:54
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Предлагаю обсудить эту идею и её жизнеспособность в реальных проектах.

В сингулярити это сделали. Правда поддержку компилятороа до ума не довели.
public contract TcpConnectionContract { 
  in message Connect(uint dstIP, ushort dstPort); 
 
  out message Ready(); 
 
  // Initial state 
  state Start : Ready! -> ReadyState; 
 
  state ReadyState : one { 
      Connect? -> ConnectResult; 
      BindLocalEndPoint? -> BindResult;  
      Close? -> Closed; 
  } 
 
  state BindResult : one { 
      OK! -> Bound; 
      InvalidEndPoint! -> ReadyState; 
  } 
 
  in message Listen(); 
 
  state Bound : one { 
      Listen? -> ListenResult; 
      Connect? -> ConnectResult; 
      Close? -> Closed; 
  } ...
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Интерфейс vs. протокол.
От: dimgel Россия https://github.com/dimgel
Дата: 13.04.11 18:59
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Такие типы называются Uniqueness type.


По первому абзацу — это вроде другое: там одна ссылка на объект, а тут надо чтобы ссылка стала невалидной после первого вызова метода. Но сначала прочитаю до конца, а ты вот лучше скажи, как такое на Немерле провернуть.
Re[4]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 13.04.11 19:06
Оценка:
Здравствуйте, dimgel, Вы писали:

D>По первому абзацу — это вроде другое: там одна ссылка на объект, а тут надо чтобы ссылка стала невалидной после первого вызова метода.

Оно самое.

D>Но сначала прочитаю до конца, а ты вот лучше скажи, как такое на Немерле провернуть.

Никак. В немерле нет uniqueness типов.
Если бы были то это делалось бы простым макросом.
И систему типов немерле без правки компилятора расширить нельзя.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Интерфейс vs. протокол.
От: dimgel Россия https://github.com/dimgel
Дата: 13.04.11 19:06
Оценка:
Здравствуйте, dimgel, Вы писали:

WH>>Такие типы называются Uniqueness type.


D>По первому абзацу — это вроде другое: там одна ссылка на объект, а тут надо чтобы ссылка стала невалидной после первого вызова метода. Но сначала прочитаю до конца, а ты вот лучше скажи, как такое на Немерле провернуть.


http://stackoverflow.com/questions/5065861/programming-languages-based-on-linear-types

there is a Scala plugin for unique types (it seems it will be "official" part of the language in the upcoming 2.9 release)


Хех, пошёл читать.
Re[5]: Интерфейс vs. протокол.
От: dimgel Россия https://github.com/dimgel
Дата: 13.04.11 19:31
Оценка:
Здравствуйте, WolfHound, Вы писали:

D>>По первому абзацу — это вроде другое: там одна ссылка на объект, а тут надо чтобы ссылка стала невалидной после первого вызова метода.

WH>Оно самое.

Написал вопрос в scala-language: http://groups.google.com/group/scala-language/browse_thread/thread/2a8d00976d9ba482
Продублирую и чуть подправлю в плане сокрытия FileImpl. Я вижу только такой вариант привести одно к другому:

class File { 
    import File.FileImpl

    def open(...) = FileImpl.get(f).open(...) 
    def close() = FileImpl.get(f).close() 
} 

object File {
    private class FileImpl { 
        def open(...): FileImpl 
        def close(): Unit 
    } 

    private object FileImpl { 
         // Every call to any File method passes through here, 
         // so any File instance can receive method call only once. 
        def get(f: File @Unique): FileImpl 
    } 
}
Re[2]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 14.04.11 04:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, 0x7be, Вы писали:


0>>Предлагаю обсудить эту идею и её жизнеспособность в реальных проектах.

WH>В сингулярити это сделали. Правда поддержку компилятороа до ума не довели.
Занятно. А что в компиляторе недоведено до ума?
Re[2]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 14.04.11 04:52
Оценка:
Здравствуйте, Sorc17, Вы писали:

S>Я понимаю о чём вы говорите, очень интересная тема. Но пример у вас совсем не показательный ...

Пример мог бы быть лучше, не спорю.

S>... То есть неправильно вызвать read()/write() это значит вообще не понимать данного интерфейса, ни зачем он, ни что делает, ни даже определение функций посмотреть. Программу же не слепоглухонемой пишет, да?

Понятно, что программист будет разбираться в интерфейсе. Вопрос в другом, как ему помочь разобраться, как помочь ему не нарушить протокол интерфейса и, что на мой взгляд важнее, как помочь программисту безопасно изменять протокол интерфейса при дальнейшей поддержке. Мое поредложение позволяет часть протокола выразить формально через систему типов языка, что позволит использовать компилятор для проверки корректности.
Re[3]: Интерфейс vs. протокол.
От: Sorc17 Россия  
Дата: 14.04.11 05:40
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Мое предложение позволяет часть протокола выразить формально через систему типов языка, что позволит использовать компилятор для проверки корректности.


Можно как-то при этом ещё оставить программисту возможность вызывать методы "не правильно"? Например я могу реализовать open(), read() и write() пустыми, потому что моя реализация интерфейса нужна только для того чтобы закрывать полученные откуда-то свыше дескрипторы вызывая close().
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re[3]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 14.04.11 06:53
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Занятно. А что в компиляторе недоведено до ума?

Нет поддержки uniqueness type.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Интерфейс vs. протокол.
От: Sorc17 Россия  
Дата: 14.04.11 07:11
Оценка:
Здравствуйте, 0x7be, Вы писали:

S>>Можно как-то при этом ещё оставить программисту возможность вызывать методы "не правильно"?

0>Зачем?

Я уже написал пример. Если вы сделаете так, что close() из "реализации интерфейса" вызвать невозможно не вызвав сначала open() да ещё и close() можно вызвать только для того, что возвращает именно тот самый вызов open(), то вы сильно ограничите применение вашего "интерфейса" как инструмента, я считаю. Если бы я хотел сделать так чтобы вызов read(), write() и close() нельзя было вызывать без open(), то я бы вовсе не выносил в интерфейс open() и close(). По-моему это логично, нет? Зачем они в интерфейсе?
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re[2]: Интерфейс vs. протокол.
От: dotneter  
Дата: 14.04.11 11:07
Оценка:
Здравствуйте, Undying, Вы писали:


U>Так бы я сказал, что проблемы с последовательностью вызовов методов это обычно архитектурная проблема, и, как правило, задачу можно решить так, что таких проблем не возникает.

Задача называется статическая проверка состояния конечного автомата, как вы ее будете решать архитектурно?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[2]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 14.04.11 11:18
Оценка:
Здравствуйте, Undying, Вы писали:


U>Непонятно в чем заключается выигрыш, при том что огромный проигрыш очевиден.

Выигрыш в том, что следование протоколу статически контролируется компилятором.

U>От проблемы с вызовом Open можно легко избавиться и так, делая его в конструкторе. Проблему с невызовом Close или вызовом его в не тот момент это код никак не помогает решить. От Close в принципе тоже можно избавиться, заменив на Finalize.

Это был лишь пример, достаточно простой.

U>Так бы я сказал, что проблемы с последовательностью вызовов методов это обычно архитектурная проблема, и, как правило, задачу можно решить так, что таких проблем не возникает.

То есть всегда можно сделать интерфейс такой, что бы в нем не было ограничений на последовательность вызовов?
Re[3]: Интерфейс vs. протокол.
От: Undying Россия  
Дата: 14.04.11 13:44
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>То есть всегда можно сделать интерфейс такой, что бы в нем не было ограничений на последовательность вызовов?


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

0>Это был лишь пример, достаточно простой.


Это был плохой пример, т.к. в нем нет последовательности шагов. В нем есть инициализация, произвольная работа, завершение, а такие задачи даже сегодняшний шарп позволяет решать почти замечательно.

0>Выигрыш в том, что следование протоколу статически контролируется компилятором.


По сути ты предлагаешь ввести в язык возможность помечать, что вызов данного метода приводит к разрушению объекта, что позволило бы компилятору контролировать, что после разрушения объекта обращений к нему не производится. Идея выглядит разумной, но проблема в том, что определить порядок вызова методов компилятор худо-бедно может только для локальных переменных, да и там по всей видимости не всегда. Соответственно область применения такой фичи окажется слишком узкой.
Re[3]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.04.11 23:17
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Такие типы называются Uniqueness type.


Я правильно понимаю, что эту хрень можно использовать вместо монад для виртуального превращения императивного кода в функциональный?

И что нужно менять в системе типов чтобы получить такие типы? Можно ли их навернуть на базе дотнетной системы типов?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 00:12
Оценка:
Здравствуйте, adontz, Вы писали:

A>Практического смысла нет никакого.


Не говори гоп...

A>Да, на примере File/Socket/Stream это красиво выглядит.


Хм. Тебе не кажется, что это заявление противоречит предыдущему?

A>А если я делаю наследника Socket и хочу наложить ограничение нельзя Read до первого Write? А когда логика начнёт зависеть от передаваемых данных, тогда что делать?


Ответ дан тут:
http://www.rsdn.ru/forum/philosophy/4232768.1.aspx
Автор: WolfHound
Дата: 13.04.11


ЗЫ

Не говори гоп пока не перепрыгнешь. Через несколько лет будешь стыдиться своих сегодняшних слов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 15.04.11 00:13
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ответ дан тут:

VD>http://www.rsdn.ru/forum/philosophy/4232768.1.aspx
Автор: WolfHound
Дата: 13.04.11


Это как-то относится к типам хоть одного мейнстримового языка? АФАИК даже Немерле так не может.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[4]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 00:27
Оценка:
Здравствуйте, adontz, Вы писали:

VD>>Ответ дан тут:

VD>>http://www.rsdn.ru/forum/philosophy/4232768.1.aspx
Автор: WolfHound
Дата: 13.04.11


A>Это как-то относится к типам хоть одного мейнстримового языка? АФАИК даже Немерле так не может.


Это вообще-то код на клоне С#.

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

Кроме того так умеют такие языки как Скала и Эрланг. Они оба не мэйнстрим. Но все же уже кое-что, не правда ли?


Ну, а уникальные типы... Если от них будет виден профит, то почему бы не прикрутить. Возможно это не так уж и сложно. Пока что, как я понимаю, нужно всего лишь пометить тип некоторым образом и во время компиляции проверять, чтобы на объект этого типа не было лишних ссылок.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 15.04.11 00:30
Оценка:
Здравствуйте, VladD2, Вы писали:

A>>Это как-то относится к типам хоть одного мейнстримового языка? АФАИК даже Немерле так не может.

VD>Это вообще-то код на клоне С#.

Там от C# одно название.

VD>Кроме того так умеют такие языки как Скала и Эрланг. Они оба не мэйнстрим. Но все же уже кое-что, не правда ли?


Ну erlang вообще довольно таки особенный язык. и ИМХО эрланг околомейнстримен.

VD>Ну, а уникальные типы... Если от них будет виден профит, то почему бы не прикрутить.


Вот я глубоко уверен, что это просто интересная фенечка, а вот использовать в продакшене это никто по своей воле не будет.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[6]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 03:21
Оценка:
Здравствуйте, adontz, Вы писали:

A>Там от C# одно название.


Отнюдь. Это C# с очень незначительными изменениями. Изучить их можно за пол часа.

VD>>Кроме того так умеют такие языки как Скала и Эрланг. Они оба не мэйнстрим. Но все же уже кое-что, не правда ли?


A>Ну erlang вообще довольно таки особенный язык. и ИМХО эрланг околомейнстримен.


Ну, вот видишь? Значит не все так печально.

VD>>Ну, а уникальные типы... Если от них будет виден профит, то почему бы не прикрутить.


A>Вот я глубоко уверен, что это просто интересная фенечка, а вот использовать в продакшене это никто по своей воле не будет.


Ты судишь на основании своих предрассудков. Я вот ничего сказать не могу. Нужно глубокое изучение вопроса.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Интерфейс vs. протокол.
От: gbear Россия  
Дата: 15.04.11 04:23
Оценка:
Здравствуйте, 0x7be, Вы писали:


0>Да, есть некоторые варианты. Например, разбить этот интерфейс на два:


0>
0>interface ISomethingProvider
0>{
0>  ISomethingOperator Open(...);
0>}

0>interface ISomethingOperator
0>{
0>  void Read(...);
0>  void Write(...);
 
0>  void Close(...);
0>}
0>

0>Имея первый интерфейс программист физически не может вызвать "не те функции" до вызова Open. Впрочем, он может вызвать
0>Read/Write после Close, что тоже есть нарушение протокола.

Хм...

interface ISomethingProvider
{
  ISomethingOperator Open(...);
  void Close(ISomethingOperator);
}

interface ISomethingOperator
{
  void Read(...);
  void Write(...); 
}
Re[4]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 06:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я правильно понимаю, что эту хрень можно использовать вместо монад для виртуального превращения императивного кода в функциональный?

Можно. Используют.
В статье даже упоминаются два языка, где этим занимаются.

VD>И что нужно менять в системе типов чтобы получить такие типы? Можно ли их навернуть на базе дотнетной системы типов?

Можно. Примерно как варианты. Те их не поймет никто кроме тех языков, которые им обучены.
Все что нужно это сделать так чтобы после чтения объекта переменная, в которой этот объект лежит, становилась недоступной.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 07:23
Оценка:
Здравствуйте, 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) А. Эйнштейн
Re[5]: Интерфейс vs. протокол.
От: dimgel Россия https://github.com/dimgel
Дата: 15.04.11 07:30
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ну, а уникальные типы... Если от них будет виден профит, то почему бы не прикрутить. Возможно это не так уж и сложно. Пока что, как я понимаю, нужно всего лишь пометить тип некоторым образом и во время компиляции проверять, чтобы на объект этого типа не было лишних ссылок.


Прочитать пока сам не добрался, но ссылочкой поделюсь: http://lamp.epfl.ch/~phaller/uniquerefs/capabilities_for_uniqueness_TR.pdf
Re[8]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 12:47
Оценка:
Здравствуйте, adontz, Вы писали:

A>Предрассудки тут не при чём. Я оцениваю ресурсы необоходимые на изучение, понимание, привыкание и потенциальный выигрыш.


Ты не можешь оценить потенциальный выигрышь пока не опробуешь фичу на практике. Твоя "колоколня" очень субъективна.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 15.04.11 12:48
Оценка:
Здравствуйте, VladD2, Вы писали:

A>>Предрассудки тут не при чём. Я оцениваю ресурсы необоходимые на изучение, понимание, привыкание и потенциальный выигрыш.

VD>Ты не можешь оценить потенциальный выигрышь пока не опробуешь фичу на практике. Твоя "колоколня" очень субъективна.

Ты абсолютно не прав. Я легко и просто могу оценить потенциальный выигрыш, просто зная количество stateful объектов.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[6]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 12:50
Оценка:
Здравствуйте, dimgel, Вы писали:

D>Прочитать пока сам не добрался, но ссылочкой поделюсь: http://lamp.epfl.ch/~phaller/uniquerefs/capabilities_for_uniqueness_TR.pdf

Статья годная хоть и как всегда несколько заумно написана.
Подход очень интересный.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 12:53
Оценка:
Здравствуйте, WolfHound, Вы писали:

Синтаксически, это:
WH>
WH>    def n = file.Read(...);//В данном случае это сахар к такому коду
WH>    def (file, n) = Read(file, ...);//Read съедает file и возвращает новый file.
WH>    ...
WH>

неудобно. Тогда нужно вводить правило по котому для уникальных объектов операция доступа к члену (x.y) схожа с передачей "х" по ссылке (y(ref x)). Тогда код будет выглядить привычно, а цель достигаться.

Правда автоматическое закрытие файла можно сделать и проще. Если программист знает, что объект должен быть закрыт до выхода из области видимости, то достаточно конструкции типа use из F# или того же using-а. Так что профит не велик, если говорить только о закрытии файла.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 13:22
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>неудобно. Тогда нужно вводить правило по котому для уникальных объектов операция доступа к члену (x.y) схожа с передачей "х" по ссылке (y(ref x)). Тогда код будет выглядить привычно, а цель достигаться.

А ты читать то что я пишу не пробовал? Ну так для разнообразия?

VD>Правда автоматическое закрытие файла можно сделать и проще. Если программист знает, что объект должен быть закрыт до выхода из области видимости, то достаточно конструкции типа use из F# или того же using-а. Так что профит не велик, если говорить только о закрытии файла.

Профит номер раз: using забыть можно. А тут не забудешь.
Профит номер два: Можно безопасно передавать и возвращать из функции.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 14:18
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>неудобно. Тогда нужно вводить правило по котому для уникальных объектов операция доступа к члену (x.y) схожа с передачей "х" по ссылке (y(ref x)). Тогда код будет выглядить привычно, а цель достигаться.

WH>А ты читать то что я пишу не пробовал? Ну так для разнообразия?

Перечитал еще раз. Ничего что бы я не читал в прошлый раз не обнаружил. Так что ты что-то там домысливаешь.

VD>>Правда автоматическое закрытие файла можно сделать и проще. Если программист знает, что объект должен быть закрыт до выхода из области видимости, то достаточно конструкции типа use из F# или того же using-а. Так что профит не велик, если говорить только о закрытии файла.

WH>Профит номер раз: using забыть можно. А тут не забудешь.

Только это ни разу не проблема. Я даже не помню когда у меня такое случалось.

WH>Профит номер два: Можно безопасно передавать и возвращать из функции.


Скорее можно безопасно "оставлять" в функции ссылку тем самым разнося логику между несколькими объектами. Потому как если логика локализована в рамках одной функции, то достаточно обеспечить закрытие ресурса при покидание области видимости (что реализуется несравнимо проще).

В общем, понятно что выгода есть. Но не очевидно, что овчинка стоит выделки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 14:21
Оценка:
Здравствуйте, adontz, Вы писали:

A>Ты абсолютно не прав. Я легко и просто могу оценить потенциальный выигрыш, просто зная количество stateful объектов.


Это другая идеолоия. Здесь оценки не уместны. Они не учитывают тучу нюансов. Я сто раз встречал болоболов-теоретиков признававших ненужными, неинтересными или даже вредными разные возможности которые лично мне были очевидны. И не раз видел как адекватные люди меняли мнение когда начинали использовать эти возможности на практике.

Так что правильно оценить фичу человек может только если она ему уже нужна, или если он использовал ее на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 14:31
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Профит номер два: Можно безопасно передавать и возвращать из функции.


А в полях то такие ссылки можно хранить? Их ведь все время обновлять придется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 14:36
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Фактически ты предлагаешь сделать объекты явными конечными автоматами, где состояние автомата будет информацией времени компиляции (т.е. каждый шаг программы будет отражен в типе чего-нибудь — либо самого объекта, либо чего-то связанного).


Ты путаешь наличие и контроля за состоянием с конечными автоматами. КА — это только один из видов представления и управления состоянием. Обратное не верно. Отличительно особенностью КА является наличие явно описываемых состояний. Здесь этого нет. Это скорее инкапсуляция состояния.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 15.04.11 14:56
Оценка:
Здравствуйте, VladD2, Вы писали:

A>>Ты абсолютно не прав. Я легко и просто могу оценить потенциальный выигрыш, просто зная количество stateful объектов.

VD>Это другая идеолоия. Здесь оценки не уместны. Они не учитывают тучу нюансов. Я сто раз встречал болоболов-теоретиков признававших ненужными, неинтересными или даже вредными разные возможности которые лично мне были очевидны. И не раз видел как адекватные люди меняли мнение когда начинали использовать эти возможности на практике.
VD>Так что правильно оценить фичу человек может только если она ему уже нужна, или если он использовал ее на практике.

Влад, как раз ты сейчас и балаболишь. вот у меня есть 1000 классов. И них 47 штук — stateful, а 953 stateless (как правило они ещё и immutable). То есть даже если этот метод распрекрасный и делает всё что только можно придумать, 47 классов это потолок его внедряемости.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[3]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 15:29
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Понятно, что программист будет разбираться в интерфейсе. Вопрос в другом, как ему помочь разобраться, как помочь ему не нарушить протокол интерфейса и, что на мой взгляд важнее, как помочь программисту безопасно изменять протокол интерфейса при дальнейшей поддержке. Мое поредложение позволяет часть протокола выразить формально через систему типов языка, что позволит использовать компилятор для проверки корректности.


Стремление похвальное. Только надо помнить, что можно перегнуть палку. Надо проверить создает ли на практике проблемы текущий подход (без этого контроля)? Даст ли ощутимые преимущества новый? И не создаст ли новый подход другие трудности, которые нивелируют преимущества?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 15:33
Оценка:
Здравствуйте, adontz, Вы писали:

A>Влад, как раз ты сейчас и балаболишь. вот у меня есть 1000 классов. И них 47 штук — stateful, а 953 stateless (как правило они ещё и immutable). То есть даже если этот метод распрекрасный и делает всё что только можно придумать, 47 классов это потолок его внедряемости.


То что у тебя есть сейчас — это продукт видения реализации в рамках знакомых тебе концепций. Это ровным счетом ничего не говорит. Уверен, что есть люди в чьих программах нет ни единого класса или даже хоть как-то сэмулированного АТД. Им попросту не знакомы эти концепции. И они свято верят, что все эти АТД и классы не нужны, так как "они же живут без них...".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 15.04.11 15:35
Оценка:
Здравствуйте, VladD2, Вы писали:

A>>Влад, как раз ты сейчас и балаболишь. вот у меня есть 1000 классов. И них 47 штук — stateful, а 953 stateless (как правило они ещё и immutable). То есть даже если этот метод распрекрасный и делает всё что только можно придумать, 47 классов это потолок его внедряемости.

VD>То что у тебя есть сейчас — это продукт видения реализации в рамках знакомых тебе концепций. Это ровным счетом ничего не говорит. Уверен, что есть люди в чьих программах нет ни единого класса или даже хоть как-то сэмулированного АТД. Им попросту не знакомы эти концепции. И они свято верят, что все эти АТД и классы не нужны, так как "они же живут без них...".

Всё что не укладывается в мейнстримные языки мне не нужно тем более.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[4]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 15:40
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Если честно, не понял, что ты хотел сказать и что из твоих слов должно следовать.


То и говорю. Наличие состояния и контроль за ним еще не означает, что это КА.

J>Явно описываемые состояния у 0x7be есть — "можно позвать метод1", "нельзя позвать метод2", и т.д. Что ты понимаешь под инкапсуляцией здесь, я тоже не понял.


КА — это реализация. А оных может быть много. С монадами знаком?

J>В общем, можешь по предложениям развернуть свою мысль?


Мысль проста. Не все что связывает вычисления является КА.

У тебя просто проявляется классическая болезнь — "когда в руках молоток, все кажется гвоздями".

В данном случае состояние и его изменение выражается через типы и объекты. На самом деле для тех же файлов все состояние будет заключаться в хранении дескриптора файла и позиции смещения внутри файла. Выражать это в виде КА никому даже в голову не придет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 15.04.11 15:48
Оценка:
Здравствуйте, 0x7be, Вы писали:

0> В частности, компоненты могут иметь протокол, то есть легальные последовательности вызовов.


interface ISomething
{
 int Status{get; set;}
 void Open(...);

 void Read(...);
 void Write(...);
 
 void Close(...);


Каждый метод в последовательности проверяет и ставит этот Status. Open проверяет, равен ли он 2 и ставит в 0. Read-Write требует 0 и ставит 1. Close требует 1 и ставит 2. При некорректном значении — exception.

Порезан жуткий оверквотинг.
WolfHound
With best regards
Pavel Dvorkin
Re[9]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 15:57
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А в полях то такие ссылки можно хранить? Их ведь все время обновлять придется.

Почитай статью Re[5]: Интерфейс vs. протокол.
Автор: dimgel
Дата: 15.04.11

Там много чего интересного написано. В том числе и про хранение в полях и про замыкание уникальных ссылок.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 15.04.11 16:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Стремление похвальное. Только надо помнить, что можно перегнуть палку. Надо проверить создает ли на практике проблемы текущий подход (без этого контроля)? Даст ли ощутимые преимущества новый? И не создаст ли новый подход другие трудности, которые нивелируют преимущества?

Дык, потому я тут и поднял тему, что мне самому это не очевидно, насколько это применимо в реальной жизни.
В моем проекте есть некий предвестник этого подхода:
interface IGuardedResource<T>
{
  IGuardedResourceSession<T> Aquire();
}

interface IGuardedResourceSession<T> : IDisposable
{
  T Resource { get; }
}

Эти два интерфейса как раз нечто подобное и реализовывали. И тут же я обдумывал вопрос, как не дать пользователю обратиться к ресурсу после Dispose`а в IGuardedResourceSession. Пришел к выводу, что средствами языка C# это сделать невозможно, поскольку T в данном варианте должен быть линейным типом.

В более масштабном варианте я свою идею не тестировал. Подозреваю, что Nemerle тут бы мог помочь с синтаксическим сахаром описания этих состояний. Если Nemerle поддерживает макросы, которые могут верифицировать код, то, может, и проблему с линейным типом решить можно.
Re[2]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 15.04.11 16:02
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Каждый метод в последовательности проверяет и ставит этот Status. Open проверяет, равен ли он 2 и ставит в 0. Read-Write требует 0 и ставит 1. Close требует 1 и ставит 2. При некорректном значении — exception.

Это убивает главный смысл моей затеи — статический контроль соблюдения протокола компилятором.
Re[3]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 15.04.11 16:10
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Каждый метод в последовательности проверяет и ставит этот Status. Open проверяет, равен ли он 2 и ставит в 0. Read-Write требует 0 и ставит 1. Close требует 1 и ставит 2. При некорректном значении — exception.

0>Это убивает главный смысл моей затеи — статический контроль соблюдения протокола компилятором.

Хм. У меня некоторое сомнение насчет статического контроля. Представь себе, что вызывать Open надо из одного C# файла, Read-Write из другого, а Close из третьего. Почему так — не обсуждаем, может, это и не очень хороший стиль, но не запретишь же.

А можно и без трех файлов. Просто сложная логика открытий, чтений и закрытий, в которой только в рантайме и можно разобраться.

А еще наследование есть и переопределение виртуальных (может быть) Open, Read, Close.
With best regards
Pavel Dvorkin
Re[4]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 15.04.11 16:17
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Хм. У меня некоторое сомнение насчет статического контроля. Представь себе, что вызывать Open надо из одного C# файла, Read-Write из другого, а Close из третьего. Почему так — не обсуждаем, может, это и не очень хороший стиль, но не запретишь же.

PD>А можно и без трех файлов. Просто сложная логика открытий, чтений и закрытий, в которой только в рантайме и можно разобраться.
Не совсем понял, чем это может помешать и как такое может быть.
Можно как-то пример конкретный придумать?

PD>А еще наследование есть и переопределение виртуальных (может быть) Open, Read, Close.

Это вопрос, да.
Но тут можно разные подходы реализовывать.
Протокол может задавать базовый класс или же он может навешиваться фасадом.
Re[5]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 15.04.11 16:19
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Хм. У меня некоторое сомнение насчет статического контроля. Представь себе, что вызывать Open надо из одного C# файла, Read-Write из другого, а Close из третьего. Почему так — не обсуждаем, может, это и не очень хороший стиль, но не запретишь же.

PD>>А можно и без трех файлов. Просто сложная логика открытий, чтений и закрытий, в которой только в рантайме и можно разобраться.
0>Не совсем понял, чем это может помешать и как такое может быть.
0>Можно как-то пример конкретный придумать?

Может, я неправильно понял, но я полагал, что под статическим контролем компилятора ты имеешь в виду контроль в дизайн-тайме. А файлы компилируются независимо.
With best regards
Pavel Dvorkin
Re[6]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 16:27
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Может, я неправильно понял, но я полагал, что под статическим контролем компилятора ты имеешь в виду контроль в дизайн-тайме. А файлы компилируются независимо.

А тебя не удивляет статический контроль за типами функций описанных в разных файлах?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 15.04.11 16:29
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Может, я неправильно понял, но я полагал, что под статическим контролем компилятора ты имеешь в виду контроль в дизайн-тайме. А файлы компилируются независимо.

Верно. Каждый кусок кода будет получать свою ссылку на состояние объекта, с которого он должен "стартовать" и дальше будет иметь возможность работать только с теми, состояниями, которые он через это получит.
Re[7]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 15.04.11 16:41
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Может, я неправильно понял, но я полагал, что под статическим контролем компилятора ты имеешь в виду контроль в дизайн-тайме. А файлы компилируются независимо.

0>Верно. Каждый кусок кода будет получать свою ссылку на состояние объекта, с которого он должен "стартовать" и дальше будет иметь возможность работать только с теми, состояниями, которые он через это получит.

Все равно идею не понимаю. Перенести в compile-time логику работы программы... Так ведь, если доводить до предела, можно потребовать в compile-time определение правильной последовательности всех действий программы. А это означает, что эта последовательность должна быть жестко фиксированной и не зависеть от данных — от них зависимость в compile-time не проверишь же...
With best regards
Pavel Dvorkin
Re[5]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 16:45
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>В более масштабном варианте я свою идею не тестировал. Подозреваю, что Nemerle тут бы мог помочь с синтаксическим сахаром описания этих состояний. Если Nemerle поддерживает макросы, которые могут верифицировать код, то, может, и проблему с линейным типом решить можно.


Nemerle тут может помочь только тем, что его код открыт и можно реализовать нужную функциональность в компиляторе. Но синтаксические навороты тут мало что дадут. Эта фича требует вмешательства в типизатор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 17:06
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Нет. Это элемент времени компиляции. Если функция требует int, то нечего ей передавать что-то иное. А вот порядок вызова функций — дело не времени компиляции, а именно рантайма.

Твое воинственное невежество уже даже не смешно.
В этом форуме было столько ссылок на работы в которых описано как контролировать на этапе компиляции значения которые известны только во время исполнения... а ты до сих пор ничего не понял. Да даже в этой ветке дана ссылка на работу в которой описан весьма остроумный способ контролировать уникальность ссылки на объект, а ты все еще ничего не знаешь.
А самое плохое в твоем поведении то что ты уперто утверждаешь что это все не нужно.
Это как "Пастернака не читал но осуждаю"

PD>Усложню и сделаю более абстрактным пример ТС.

Да хоть заусложняйся.

PD>Как это контролировать в complile-time ,

Вот так:
interface ISomething
{
    state S1 S2 S3;
    void First  @ S1 -> S2 | S3(...);
    void Second @ S2 -> S1 | S3(...);
    void Third  @ S3 -> S1(...);
}
ISomething @ S2 Foo(ISomething @ S1 some)
{
    some.First(...);//После этого вызова нас some меняет тип
    //на ISomething @ S2 | S3
    //это значит что some может находится в одном из двух состояний
    match (some)//Проверяем тип some
    {//На ISomething @ S1 компилятор ругнется ибо этого варианта быть не может.
        | ISomething @ S2 =>
            return some;

        | ISomething @ S3 =>
            some.Thrid(...)
            //Тут компилятор знает что some имеет тип ISomething @ S1
            return Foo(some);//Хвостовые вызовы стек не едят
    }
}
...
//Безопасно вызываем Second
Foo(...).Second(...);

Вот таким образом этот код будет крутиться пока не попадет в состояние S2

PD>я не понимаю,

Это из-за твоего невежества.

PD>а главное — не понимаю зачем.

Ровно за тем же за чем контролировать чтобы вместо int string не воткнули.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 17:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Nemerle тут может помочь только тем, что его код открыт и можно реализовать нужную функциональность в компиляторе. Но синтаксические навороты тут мало что дадут. Эта фича требует вмешательства в типизатор.

В скале проверка уникальности идет после того как отработал основной типизатор.
Так что если сделать возможность вставлять свои анализаторы которые работают после основного вывода типов то эту фичу можно будет прикрутить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 17:10
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Все равно идею не понимаю. Перенести в compile-time логику работы программы... Так ведь, если доводить до предела, можно потребовать в compile-time определение правильной последовательности всех действий программы. А это означает, что эта последовательность должна быть жестко фиксированной и не зависеть от данных — от них зависимость в compile-time не проверишь же...

Сколько еще лет тебе показывать эту ссылку?

In computer science and logic, a dependent type is a type that depends on a value.

http://en.wikipedia.org/wiki/Dependent_type
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 17:32
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>В скале проверка уникальности идет после того как отработал основной типизатор.

WH>Так что если сделать возможность вставлять свои анализаторы которые работают после основного вывода типов то эту фичу можно будет прикрутить.

Можно тупо влепить событие которое вызывать после Tx-шагов.

Событию передавать номер шага и TExpt тела метода. Ну, и если событие возвращает не null а другой TExpt, заменять им тело метода.

Но ведь типы как-то надо будет помечать. Иначе не ясно для каких переменных анализ делать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 17:38
Оценка:
Здравствуйте, adontz, Вы писали:

A>Давай я тебя спущу на землю. Напиши руками (никаких PEG/Antlr/CoCoR) парсер HTML, самый примитивный и с упрощениями. А потом мы поговрим как это круто описывать НКА руками в коде.

А давай ты пойдешь читать сырци сингулярити. Там полно работы с протоколами.
Кстати то что ты упорно повторяешь НКА тоже кое что говорит о тебе. Ибо тут ДКА. Разница огромна.
Вот простой пример:
    public contract CalculatorContract : ServiceContract {
        out  message Success();

        in   message AddInteger(int first, int second);
        out  message IntegerResult(int answer);

        in   message SubtractInteger(int first, int second);

        override state Start: one {
            Success! -> Ready;
        }

        state Ready: one {
            AddInteger? -> IntegerResult! -> Ready;

            SubtractInteger? -> IntegerResult! -> Ready;
        }
    }

    public class BounceBackServer
    {
        public static int Main(String[] args)
        {
            DirectoryServiceContract.Imp! dirImp;

            dirImp = DirectoryService.NewClientEndpoint();

            ServiceProviderContract.Imp! nsImp;
            ServiceProviderContract.Exp! nsExp;
            ServiceProviderContract.NewChannel(out nsImp, out nsExp);

            string location = "/BounceBackServer";
            ErrorCode error;
            if (!SdsUtils.Register(location, dirImp, nsImp, out error)) {
                DebugStub.WriteLine("Failed to register in BSP namespace error {0}\n",
                                    __arglist(SdsUtils.ErrorCodeToString(error)));
                delete nsExp;
                delete dirImp;
                return -1;
            }

            // Here is the set of client channels we service
            ESet<CalculatorContract.Exp:Ready> epSet = new ESet<CalculatorContract.Exp:Ready>();
            while (true) {
                switch receive {

                    case nsExp.Connect(ServiceContract.Exp:Start! exp) :
                        CalculatorContract.Exp calculatorExp  = exp as CalculatorContract.Exp;
                        if(calculatorExp == null) {
                            nsExp.SendNackConnect(exp);
                        }
                        else {
                            DebugStub.Print("Received new ServerControl\n");
                            calculatorExp.SendSuccess();
                            epSet.Add(calculatorExp);
                            nsExp.SendAckConnect();
                        }
                        break;

                    case ep.AddInteger(int first, int second) in epSet :
                        DebugStub.Print("Server received add integer request\n");
                        int result = first + second;
                        ep.SendIntegerResult(result);
                        epSet.Add(ep);
                        break;

                    case ep.SubtractInteger(int first, int second) in epSet :
                        DebugStub.Print("Server received subtract integer request\n");
                        int result = first - second;
                        ep.SendIntegerResult(result);
                        epSet.Add(ep);
                        break;

                    case ep.ChannelClosed() in epSet :
                        delete ep;
                        break;

                    case epSet.Empty() && nsExp.ChannelClosed() :
                        delete nsExp;
                        epSet.Dispose();
                        delete dirImp;
                        return -1;
                        break;

                    case unsatisfiable :
                        DebugStub.Break();
                        break;
                }
            }
            delete dirImp;

            return 0;
        }
    }

delete тут конечно лишние но все остальное ты короче ни на чем не напишешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 17:43
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Можно тупо влепить событие которое вызывать после Tx-шагов.

Tx-шагов чего?
Типизатора?
Нафиг.
Я тебе еще раз говорю в скале это совершенно независимый от основного типизатора процесс который работает после того как отработал основной типизатор.
После основного типизатора можно на самом деле очень много чего делать.
Например можно прикрутить type refiments. Котрые почти такие же крутые как depended types.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 18:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


VD>>Можно тупо влепить событие которое вызывать после Tx-шагов.

WH>Tx-шагов чего?

T2, T3, T4. Шаги Т3-Т4 в интеграции не осуществляются (только в компиляторе).

WH>Типизатора?

WH>Нафиг.
WH>Я тебе еще раз говорю в скале это совершенно независимый от основного типизатора процесс который работает после того как отработал основной типизатор.

Эти шаги и выполняются после окончания работы основного типизатора (T1).

На каждом из этих шагов производится некоторая трасформация. Например, генерируются замыкания и обвязка для них.

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

WH>
После основного типизатора можно на самом деле очень много чего делать.

Я в курсе. Не раз сам делал. Только у меня код компилятора под рукой и мне плагины не нужны .

WH>Например можно прикрутить type refiments. Котрые почти такие же крутые как depended types.


Остается только пара вопросов. Зачем оно надо? и Как помечать типы? Ведь после Т1 можно только трансформировать результат.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 18:07
Оценка:
Здравствуйте, adontz, Вы писали:

A>Давай без перехода на личности, тем более что ты не прав.

Ой Рама... лол.
Я по уши в автоматах. Так шта...

A>Есть состояния CanExecute{X}. Изначально автомат в состоянии CanExecuteOpen. Потом он переходит сразу в три состояния (НКА, однако): CanExecuteRead, CanExecuteWrite, CanExecuteClose. Ну и т.д.

Есть состояние Closed из которого можно вызвать только Open.
Есть состояние Ready из которого можно вызвать Read, Write, Close.
Closed -> Open -> Ready
Ready -> Write -> Ready
Ready -> Read -> Ready
Ready -> Close -> Closed
Вот реальное состояние дел.
И где тут НКА?

A>Причём переход между состояниями может определяться не только типом сообщения, но и его содержимым, так что метод либо невозможно будет применить, либо он искуственно породит кучу лишних типов.

Ты пример РЕАЛЬНОГО кода который я тебе показал посмотри.

A>Хорошо, что ты только что сам признался, что описанный метод не подходит для решения реальных задач. Я это с самого начала и говорил.

Это как "отверткой нельзя забивать гвозди". А ты "Я же говорил что отвертки для реальной работы не подходят.".
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 18:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Остается только пара вопросов. Зачем оно надо? и Как помечать типы? Ведь после Т1 можно только трансформировать результат.

Статью прочитай.
Автор: dimgel
Дата: 15.04.11
Там все написано. И как и зачем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 18:22
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Остается только пара вопросов. Зачем оно надо? и Как помечать типы? Ведь после Т1 можно только трансформировать результат.

WH>Статью прочитай.
Автор: dimgel
Дата: 15.04.11
Там все написано. И как и зачем.


Статью я с горем пополам распечатал. Будет время, почитаю.


Но на вопрос "зачем оно надо?" она вряд ли даст ответ. Тут нужен опыт реального применения.
Да и на второй вопрос ответ интересен в разрезе немерлового компилятора, а не общей теории.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 15.04.11 18:29
Оценка:
Здравствуйте, VladD2, Вы писали:

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


J>>Если честно, не понял, что ты хотел сказать и что из твоих слов должно следовать.


VD>То и говорю. Наличие состояния и контроль за ним еще не означает, что это КА.


В общем случае — может быть (хотя математически сам компьютер — это КА, и соответственно все, что на нем работает, тоже КА), но вот в этом конкретном обсуждаемом случае я вижу КА в чистом и незамутненном виде. Объясни, почему то, о чем говорит 0x7be — это не КА.

J>>Явно описываемые состояния у 0x7be есть — "можно позвать метод1", "нельзя позвать метод2", и т.д. Что ты понимаешь под инкапсуляцией здесь, я тоже не понял.


VD>КА — это реализация. А оных может быть много. С монадами знаком?


Знаком. Чем КА-то не угодил, если он укладывается в требования 0x7be? И КА — это в первую очередь математическая абстракция объекта с состоянием и графом разрешенных переходов: http://en.wikipedia.org/wiki/Finite-state_machine. Так что это не КА — реализация, а КА допускает много реализаций.


J>>В общем, можешь по предложениям развернуть свою мысль?


VD>Мысль проста. Не все что связывает вычисления является КА.

Замечательно. Конструктивная мысль будет? или все ограничится сотрясанием воздуха в стиле "совы не то, чем кажутся"? И, главное, чем плох КА? Тем, что на свете есть еще что-то, кроме КА?

VD>У тебя просто проявляется классическая болезнь — "когда в руках молоток, все кажется гвоздями".

Ахтунг, психиатры в форуме!

VD>В данном случае состояние и его изменение выражается через типы и объекты. На самом деле для тех же файлов все состояние будет заключаться в хранении дескриптора файла и позиции смещения внутри файла. Выражать это в виде КА никому даже в голову не придет.


Да ну? А если файл открыть не удалось, много тебе скажут дескриптор и смещение? А после закрытия файла они тебе о чем скажут? Так что извини, файл (как его описал 0x7be) представляет собой КА с как минимум двумя состояниями: "Открыт" и "Не открыт". Далее, когда ты доехал до конца файла, больше ты читать из него не можешь. Так что в рамках "Открыт" есть еще два состояния: "Можно читать" и "Нельзя читать".
Я не знаю, что ты имеешь в виду под "Выражать это в виде КА", но любой флаг, который заводишь в объекте и который влияет на его поведение, автоматом вводит множество состояний, соответствующее значению этого флага. Скажем, тот же дескриптор — допустим, он в данной ОС не может быть нулевым для открытого файла. Значит, он у нас, помимо хранения собственно дескриптора, играет дополнительно еще роль флага благодаря специальному нулевому значению, обеспечивая переходы из состояния "не открыт" в состояние "открыт" (метод Open) и обратно (метод Close). И только так! Нельзя из состояния "открыт" перейти снова в состояние "открыт" при помощи Open, потому что будет утечка открытого дескриптора. Точно так же позиция играет роль индикатора состояния "можно читать"/"нельзя читать", только выделенное значение будет не нулевое, а соответствующее концу файла. Все еще считаешь, что файл — это не КА?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[12]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 19:03
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Но на вопрос "зачем оно надо?" она вряд ли даст ответ. Тут нужен опыт реального применения.

Дает. Я об этом способе применения уникальных типов еще несколько лет назад писал.

VD>Да и на второй вопрос ответ интересен в разрезе немерлового компилятора, а не общей теории.

Я не думаю что в данном контексте между немерлом и скалой есть хоть какаято разница.
А в статье описаны правила проверки типов которые вообще ни к какому языку не привязаны и могут быть навешаны на какой угодно язык.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 19:17
Оценка:
Здравствуйте, adontz, Вы писали:

A>Ты "в уме" создал для НКА соответствующий ДКА, а теперь пытаешься меня убедить что так и было?

Да, так и было.

A>Нет, не выйдет. Давай немножечко усложним задачу. После Open можно вызвать Read или Write, но потом их надо чередовать.

A>Получим НКА
A>CanOpen -{Open}-> CanRead,CanWrite,CanClose
A>CanRead -{Read}-> CanWrite,CanClose
A>CanWrite -{Write}-> CanRead,CanClose
A>CanClose -{Close} -> nil (пустое множество)
ЛОЛ! Рома ты мне не поверишь но это просто альтернативный метод записать ДКА
Вот это "CanRead,CanWrite,CanClose" состояние.
Из него 3 перехода в состояния "CanWrite,CanClose", "CanRead,CanClose" и nil.
Я вот это могу засунуть в систему типов и использовать как есть. Без всяких трансформаций.

A>Посмотрел. Примитивизм, подогнанный под инструмент. Зато я тебе могу дать действительно реальный пример. Реализовываем сетевой протокол (практически любой). Надо прочитать запрос клиента до конца прежде чем ответить. То есть можно ли после очередного Read выполнять Read или Write определяется прочитанными данными. То есть, цитируя себя самого, "переход между состояниями может определяться не только типом сообщения, но и его содержимым". Естественно, описать это на уровне типов не получится.

Рома ты просто фееричен.
На читай:
  Скрытый текст
namespace NetStack.Contracts
{
    public enum TcpError
    {
        Unknown = 1,
        AlreadyConnected,       // this connection is already in use
        Refused,                // the receiving host actively refused the connection
        Reset,                  // the connection was reset
        Timeout,                // no response was received
        ProtocolViolation,      // we received a TCP segment that is not acceptable in the current state
        ResourcesExhausted,     // out of memory, etc.
        Closed,                 // remote peer has closed socket
    }

    public contract TcpConnectionContract
    {
        // Requests
        in message Connect(uint dstIP, ushort dstPort);
        in message BindLocalEndPoint(uint dstIP, ushort dstPort);

        //
        // Initial state; there is a gratuitous Ready message to
        // ensure the Exp side has been connected before it accepts
        // any messages.
        //
        out message Ready();

        state Start : Ready! -> ReadyState;

        state ReadyState : one
        {
            Connect? -> ConnectResult; // Can connect without binding first
            BindLocalEndPoint? -> BindResult; // Can't listen without binding first
            Close? -> Closed;
        }

        //
        // Binding to a local endpoint
        //
        state BindResult : one
        {
            OK! -> Bound;
            InvalidEndPoint! -> ReadyState;
        }

        in message Listen(int backlog);

        state Bound : one
        {
            Listen? -> ListenResult;
            Connect? -> ConnectResult;
            Close? -> Closed;
        }

        //
        // Attempts to connect to a remote host
        //
        out message OK();
        out message CouldNotConnect(TcpError error);

        state ConnectResult : one
        {
            CouldNotConnect! -> ReadyState;
            OK! -> Connected;
        }

        //
        // Attempts to listen for inbound connections
        //
        out message CouldNotListen();

        state ListenResult : one
        {
            CouldNotListen! -> ReadyState;
            OK! -> Listening;
        }

        out message InvalidEndPoint();

        in message GetLocalAddress();
        in message GetLocalPort();
        in message Accept(TcpConnectionContract.Exp:PreConnected! newConnection);
        in message IsSessionAvailable(); // Is there a new session waiting to be serviced?

        out message IPAddress(uint ip);
        out message Port(ushort port);
        out message SessionIsAvailable(bool isAvailable);

        state Listening : one
        {
            GetLocalAddress? -> IPAddress! -> Listening;
            GetLocalPort? -> Port! -> Listening;
            IsSessionAvailable? -> SessionIsAvailable! -> Listening;
            Accept? -> OK! -> Listening; // Blocks until a connection is received

            Close? -> Closed;
        }

        //
        // The pre-connected state exists so we can confirm that the endpoint
        // has been wired to the NetStack before accepting messages on it
        //
        state PreConnected : Ready! -> Connected;

        //
        // Operations on an established connection
        //

        // Requests
        in message Read(); // Read as much data as possible without blocking
        in message PollRead(int timeout); // Wait up to timeout ms for data
        in message IsDataAvailable(); // Is there queued data that can be read immediately?
        in message Write(byte[]! in ExHeap data);
        in message Close(); // Performs a non-blocking but graceful shutdown
        in message Abort(); // Performs an immediate, hard close (unsent data is discarded)
        in message GetRemoteAddress();
        in message GetRemotePort();
        in message DoneSending();
        in message DoneReceiving();

        // Response messages
        out message ConnectionClosed(); // Connection has been shut down
        out message NoData(); // There was nothing to read
        out message NoMoreData(); // Will never be more data
        out message CantSend(); // Remote side refuses more data
        out message Data(byte[]! in ExHeap data);
        out message DataIsAvailable(bool isAvailable);

        state Connected : one
        {
            Read? -> ReadResult;
            PollRead? -> PollReadResult;
            Write? -> WriteResult;

            IsDataAvailable? -> (DataIsAvailable!) -> Connected;
            GetLocalAddress? -> IPAddress! -> Connected;
            GetLocalPort? -> Port! -> Connected;
            GetRemoteAddress? -> IPAddress! -> Connected;
            GetRemotePort? -> Port! -> Connected;

            DoneSending? -> ReceiveOnly;
            DoneReceiving? -> SendOnly;
            Close? -> Closed;
            Abort? -> Closed;
        }

        state ReadResult : one
        {
            Data! -> Connected;
            // This indicates that there will never be any more
            // data, but that sending is still allowed
            NoMoreData! -> SendOnly;
            // This indicates that sending has been closed by the
            // remote side
            ConnectionClosed! -> Zombie;
        }

        state PollReadResult : one
        {
            Data! -> Connected;
            // No data available within the poll window; try again
            NoData! -> Connected;
            NoMoreData! -> SendOnly;
            ConnectionClosed! -> Zombie;
        }

        state WriteResult : one
        {
            OK! -> Connected;
            // This indicates that writing has been closed by the
            // remote side, but reading is still allowed.
            CantSend! -> ReceiveOnly;
        }

        //
        // Operations on a receive-only connection (send side has been closed)
        //
        state ReceiveOnly : one
        {
            Read? -> ROReadResult;
            PollRead? -> ROPollReadResult;

            IsDataAvailable? -> (DataIsAvailable!) -> ReceiveOnly;
            GetLocalAddress? -> IPAddress! -> ReceiveOnly;
            GetLocalPort? -> Port! -> ReceiveOnly;
            GetRemoteAddress? -> IPAddress! -> ReceiveOnly;
            GetRemotePort? -> Port! -> ReceiveOnly;

            DoneReceiving? -> Zombie;
            Close? -> Closed;
            Abort? -> Closed;
        }

        state ROReadResult : one
        {
            Data! -> ReceiveOnly;
            // If there is no more data, there's nothing more to do.
            NoMoreData! -> Zombie;
        }

        state ROPollReadResult : one
        {
            Data! -> ReceiveOnly;
            NoData! -> ReceiveOnly;
            NoMoreData! -> Zombie;
        }

        //
        // Operations on a send-only connection (receive side has been closed)
        //
        state SendOnly : one
        {
            Write? -> SOWriteResult;

            GetLocalAddress? -> IPAddress! -> SendOnly;
            GetLocalPort? -> Port! -> SendOnly;
            GetRemoteAddress? -> IPAddress! -> SendOnly;
            GetRemotePort? -> Port! -> SendOnly;

            DoneSending? -> Zombie;
            Close? -> Closed;
            Abort? -> Closed;
        }

        state SOWriteResult : one
        {
            OK! -> SendOnly;
            // Remote side refuses further data
            CantSend! -> Zombie;
        }

        //
        // Zombied connection (nothing left to do but user hasn't explicitly
        // closed yet)
        //
        state Zombie : one
        {
            Close? -> Closed; // Wrap up gracefully
            Abort? -> Closed; // Drop any unsent data
        }

        state Closed : {} // Nothing is acceptable here
    }
}


A>Совсем даже не так, потому что гвозди всё же весьма распространены, а КА с фиксированным и малым числом возможных переходов — нет.

Скачай уже исходники сингулярити.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.11 19:19
Оценка:
Здравствуйте, jazzer, Вы писали:

VD>>То и говорю. Наличие состояния и контроль за ним еще не означает, что это КА.


J>В общем случае — может быть


А наш случай частный?

J> (хотя математически сам компьютер — это КА, и соответственно все, что на нем работает, тоже КА),


Ой как интересно! С удовольствием послушаю о том какое состояние конечное у компьютера.

А машина Тьюринга или лямбда-исчисления Черча — это тоже КА? Тогда можно за одно рассказать и о конечном состоянии машины Тьюринга.

J> но вот в этом конкретном обсуждаемом случае я вижу КА в чистом и незамутненном виде. Объясни, почему то, о чем говорит 0x7be — это не КА.


Да всем. Нет входных данных, например. Да и вообще никаких атрибутов КА. Не, безусловно, многие задачи можно описать в том числе и КА. Но и без них тоже можно. При этом КА описывают не все задачи. Например, бесконечные (рекурсивные) или задачи требующие для работы дополнительной памяти (например, парсинг).

По сему не надо привязывать сюда КА. Они тут не причем. Вот внутри уникального типа может использоваться КА для обработки логики. Но уникаьные типы сами по себе — это всего лишь контроль за тем, чтобы в один момент времени на объект не было более одной ссылки. А логика у него может быть любой сложности, как укладывающейся в КА, так и не укладывающейся.

J>>>Явно описываемые состояния у 0x7be есть — "можно позвать метод1", "нельзя позвать метод2", и т.д. Что ты понимаешь под инкапсуляцией здесь, я тоже не понял.


VD>>КА — это реализация. А оных может быть много. С монадами знаком?


J>Знаком. Чем КА-то не угодил, если он укладывается в требования 0x7be?


Тем что ты их за уши притянул. Я с тем же успехом могу притянуть монады. Они тоже позволяют связать вычисления.

J> И КА — это в первую очередь математическая абстракция


Есть много мат.абстракций. И что? Эта интересна тем, что ты ей уделил больше внимания?

J>объекта с состоянием и графом разрешенных переходов: http://en.wikipedia.org/wiki/Finite-state_machine. Так что это не КА — реализация, а КА допускает много реализаций.


Где ты переходы то усмотрел? У тебя метод может получить ссылку и она может остаться в нем.

J>Да ну? А если файл открыть не удалось, много тебе скажут дескриптор и смещение?


Многое. Хэндл будет некорректным (например, равный нулю).
Меня другое интересно. А что делать, если система типов сложнее чем в случае открытия файлов?

Пойми. Ну, нельзя прописать какую-то сложную логику в типах. Только простой набор связей. Там и вычислений то никаких не будет. Это чистая декларация.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 15.04.11 19:45
Оценка:
Здравствуйте, adontz, Вы писали:

A>Да, он называется НКА.

Нет. Тут именно что ДКА записан.

WH>>Вот это "CanRead,CanWrite,CanClose" состояние.

A>Если НКА преобразовать в ДКА.
Я знаю как из НКА делают ДКА. Так вот тут никаких преобразований не недо.
Совсем.
Это можно прямо так в коде использовать.

A>"NoMoreData! -> SendOnly;" это твои фантазии, а не парсинг запроса.

Это протокол работы с TCP/IP из реально работающей системы.

A>Сингуларити... дай вспомнить.... Веб-сервер в 8 раз медленее на там же железе, 50Мб/с — максимальная пропускная способность TCP/IP стека и твои уверения, что безопасность не влияет на скорость. Нет, не интересно.

Рома ты просто фееричен. Сравнивать вылизанную ОС и вылизанный веб сервер с экспериментальной системой...
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 15.04.11 20:27
Оценка:
Здравствуйте, WolfHound, Вы писали:

A>>"NoMoreData! -> SendOnly;" это твои фантазии, а не парсинг запроса.

WH>Это протокол работы с TCP/IP из реально работающей системы.

Значит эта система значительно примитивнее популярных систем.

A>>Сингуларити... дай вспомнить.... Веб-сервер в 8 раз медленее на там же железе, 50Мб/с — максимальная пропускная способность TCP/IP стека и твои уверения, что безопасность не влияет на скорость. Нет, не интересно.

WH>Рома ты просто фееричен. Сравнивать вылизанную ОС и вылизанный веб сервер с экспериментальной системой...

Вот не надо ля-ля. Вылизать можно тормоза в раза в два, а 50Мбит/с, это тормоза в 20 раз и это архитектурные проблемы.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[9]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 16.04.11 07:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:


WH>А самое плохое в твоем поведении то что ты уперто утверждаешь что это все не нужно.


Не утверждаю, а сомневаюсь.

WH>Это как "Пастернака не читал но осуждаю"


Это явно не к месту.

WH>Да хоть заусложняйся.


Тогда упростим. Я подобный вопрос уже несколько раз задавал. От своего невежества, конечно. Только почему-то никто на него не ответил. Вот давай ответь.

Итак...

Мне надо вычислить :
При отрицательном f — корень модуля f
При положительном f — минус корень f
При 0, сам понимаешь, все равно.

Пишу вот такой код (к коду не придираться и не объясять, как его можно изменить)


class A{
 public float SqRoot(float f) {return sqrt(f);}
 public float Minus(float f) { return -f;}
 public float Func(float f)
 {
   if(f < 0)
    return Minus(SqRoot(f));
   else
    return SqRoot(Minus(f));
}


Меня сомнение гложет — в правильном порядке я функции вызываю или нет в Func ?. Может, надо было наоборот ? 2 теста в рантайме дадут вполне определенный ответ.

WH>Это из-за твоего невежества.


Ну вот я тебе пример привел выше, с минусом и корнем. Объясни просто и понятно, каким образом, не запуская программы, можно проверить правильность порядка вызова функций. Продемонстрируй свои знания в ответ на мое невежество. Только, пожалуйста, останься в рамках предложенного ТС C#.
With best regards
Pavel Dvorkin
Re[10]: Интерфейс vs. протокол.
От: hardcase Пират http://nemerle.org
Дата: 16.04.11 07:26
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну вот я тебе пример привел выше, с минусом и корнем. Объясни просто и понятно, каким образом, не запуская программы, можно проверить правильность порядка вызова функций. Продемонстрируй свои знания в ответ на мое невежество. Только, пожалуйста, останься в рамках предложенного ТС C#.


В C# нет зависимых типов. Так что тут только PEX может найти логические ошибки.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[11]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 16.04.11 08:36
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Ну вот я тебе пример привел выше, с минусом и корнем. Объясни просто и понятно, каким образом, не запуская программы, можно проверить правильность порядка вызова функций. Продемонстрируй свои знания в ответ на мое невежество. Только, пожалуйста, останься в рамках предложенного ТС C#.


H>В C# нет зависимых типов. Так что тут только PEX может найти логические ошибки.


Ну ладно, пусть не C#. Объясни просто на пальцах — каким вообще образом, не запуская этот код, можно сказать, в правильном ли порядке я вызвал функции или нет ?
With best regards
Pavel Dvorkin
Re[10]: Интерфейс vs. протокол.
От: Sorc17 Россия  
Дата: 16.04.11 09:13
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>
PD>class A{
PD> public float SqRoot(float f) {return sqrt(f);}
PD> public float Minus(float f) { return -f;}
PD> public float Func(float f)
PD> {
PD>   if(f < 0)
PD>    return Minus(SqRoot(f));
PD>   else
PD>    return SqRoot(Minus(f));
PD>}

PD>


PD>Ну вот я тебе пример привел выше, с минусом и корнем. Объясни просто и понятно, каким образом, не запуская программы, можно проверить правильность порядка вызова функций. Продемонстрируй свои знания в ответ на мое невежество. Только, пожалуйста, останься в рамках предложенного ТС C#.


Вопрос был не мне Но у меня есть идея как можно это сделать не запуская программы. Если где-то "запомнить", что аргумент sqrt() должен быть больше нуля, то можно для всех вызовов sqrt() проверить, гарантировано ли ему передастся положительное число. Отсюда можем найти сомнительное место в SqRoot(), для него тоже запомним, что ему должен передаваться аргумент больше нуля, чтобы и в sqrt() он пришел положительным. Исследуя вызовы SqRoot() можно обнаружить, что ему передаётся в качестве аргумента результат выполнения Minus() а её возвращаемое значение может быть меньше нуля, значит в строчке

    return SqRoot(Minus(f));

можно смело выдать ворнинг.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
Re[11]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 16.04.11 09:28
Оценка:
Здравствуйте, Sorc17, Вы писали:

S>Вопрос был не мне Но у меня есть идея как можно это сделать не запуская программы. Если где-то "запомнить", что аргумент sqrt() должен быть больше нуля, то можно для всех вызовов sqrt() проверить, гарантировано ли ему передастся положительное число.


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

>Отсюда можем найти сомнительное место в SqRoot(), для него тоже запомним, что ему должен передаваться аргумент больше нуля, чтобы и в sqrt() он пришел положительным.


Интересная история. А если в ней перед sqrt выполняется некая обработка этого f, результат которой даже в принципе предвидеть нельзя, если не просчитать ? Например, f — стартовая точка для итерационного решения уравнения, а какой там корень уравнения получится, если с нее стартануть — бог знает (предполагаю, что у уравнения не 1 корень). Не возьмешься же ты ответить на вопрос, будет корень уравнения положительным или отрицательным, если начать итерации с некоторого f.
With best regards
Pavel Dvorkin
Re[10]: Интерфейс vs. протокол.
От: dotneter  
Дата: 16.04.11 09:39
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

Что вам мешает сделать как то так?
class A{
 public IPlus SqRoot(IPlus f) {return sqrt(f);}
 public IMinus Minus(IPlus f) { return -f;}
 public IPlus Minus(IMinus f) { return -f;}
 public IPlus Func(IPlus f)
 {
    return Minus(SqRoot(f));
}

public IPlus Func(IMinus f)
 {
    return SqRoot(Minus(f));
}

По сути вы значение f вместе с условием if выносите в тип.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[11]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 16.04.11 09:45
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, Pavel Dvorkin, Вы писали:


D>Что вам мешает сделать как то так?

D>
D>class A{
D> public IPlus SqRoot(IPlus f) {return sqrt(f);}
D> public IMinus Minus(IPlus f) { return -f;}
D> public IPlus Minus(IMinus f) { return -f;}
D> public IPlus Func(IPlus f)
D> {
D>    return Minus(SqRoot(f));
D>}

D>public IPlus Func(IMinus f)
D> {
D>    return SqRoot(Minus(f));
D>}


D>

D>По сути вы значение f вместе с условием if выносите в тип.

А все же на вход Func должна передаваться переменная типа float. Я не знаю, положительна она или отрицательна, ее с консоли введут. Кроме того, Func должна вернуть IMinus, (при положительном f — минус корень f). Что-то не клеится.
With best regards
Pavel Dvorkin
Re[12]: Интерфейс vs. протокол.
От: dotneter  
Дата: 16.04.11 09:55
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А все же на вход Func должна передаваться переменная типа float. Я не знаю, положительна она или отрицательна, ее с консоли введут.

Это как чистые функции и IO, что то нужно придумать что бы их подружить, так же и здесь. Есть внешний мир при соедитетие с программой нужно что то сделать что бы данные перевести в типы, можно тот же if, а можно наверное что то еще, суть в том что вне зависимости что там будет происходить у вас есть описание функций решающие вашу проблему и при этом устраняют возможные ошибки которые в них могли бы содержаться.

PD>Кроме того, Func должна вернуть IMinus, (при положительном f — минус корень f). Что-то не клеится.

Да, при этом эту ошибку сможет найти компилятор.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[12]: Интерфейс vs. протокол.
От: dotneter  
Дата: 16.04.11 10:03
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

Можно рассмотреть пример проще

public void DoSomething(A a){
    if(A == null)
       throw new ArgumentException(a);
}
public void DoSomething(NotNull<A> a){

}



То есть где то эта проверка должна произойти, либо у каждой функции, либо вы можете ее сделать один раз, и тогда у вас по программе будет гулять переменная у которой в типе NotNull<A> уже содержится какая то информация о ее значении;
Talk is cheap. Show me the code.
Re[8]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 16.04.11 10:03
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Все равно идею не понимаю. Перенести в compile-time логику работы программы... Так ведь, если доводить до предела, можно потребовать в compile-time определение правильной последовательности всех действий программы. А это означает, что эта последовательность должна быть жестко фиксированной и не зависеть от данных — от них зависимость в compile-time не проверишь же...


Попробую проиллюстрировать свою идею. Положим, есть у нас сервер, умеющий что-нибудь считать.
Для того, что бы работать с ним надо:
1. Открыть сессию.
2. Загрузить данные.
3. Вызвать функцию вычисления (их может быть много).
4. Если вычисление прошло успешно, то выгрузить данные.
5. Закрыть сессию.

Как бы выглядел "обчный" порошо... интерфейс сервера и сессии:
interface IServer
{
  ISession CreateSession();
}

interface ISession : IDisposable
{
  void UploadData(Data);
  Data DownloadData();

  bool DoFuncA();
  bool DoFuncB();
  bool DoFuncC();
}

Интерфейс сервера меня устраивает, поработаю над интерфейсом сессии.

interface ISessionUploadData : IDisposable
{
  Variant<ISessionDoJob, ISessionUploadData> UploadData(Data);
}

interface ISessionDoJob : IDispoable
{
  Variant<ISessionDownloadData, IDisposable> DoFuncA();
  Variant<ISessionDownloadData, IDisposable> DoFuncB();
  Variant<ISessionDownloadData, IDisposable> DoFuncC();
}

interface ISessionDownloadData : IDisposable
{
  Tuple<Data, IDisposable> DownloadData();
}

Все интерфейсы наследуются от IDisposable, что означает, что закрыть сессию можно в любой момент.

Обрати внимание на Variant. По сути это должен быть алгебраический тип, в который можно завернуть несколько вариантов возврата, параллельно с нужными кодами возврата (ошибки и т.п.)

В частности, функция UploadData в случае успеха возвращает ISessionDoJob, что бы продолжать работать с данными, либо снова ISessionUploadData, если данные не загрузились.

Функции вычисления возвращают либо ISessionDownloadData, если вычисление прошло, либо IDisposable, если ошибка.

То есть нет возможности вызвать функцию обработки данных до её загрузки или если загрузка обломалась.
И нет возможности вызвать функцию скачки результата, если данные не были обработаны.

Дальше, положим что мы решили поменять протокол. Сказали, что после загрузки но перед обработкой надо вызвать функцию PreparеData, которая как-нибудь данные готовит. Мы меняем интерфейсы, добавляя ISessionPrepareData "между" ISessionUploadData и ISessionDoJob:
interface ISessionUploadData : IDisposable
{
  Variant<ISessionPrepareData, ISessionUploadData> UploadData(Data);
}

interface ISessionPrepareData : IDisposable
{
  ISessionDoJob UploadData(Data);
}

interface ISessionDoJob : IDispoable
{
  Variant<ISessionDownloadData, IDisposable> DoFuncA();
  Variant<ISessionDownloadData, IDisposable> DoFuncB();
  Variant<ISessionDownloadData, IDisposable> DoFuncC();
}

interface ISessionDownloadData : IDisposable
{
  Tuple<Data, IDisposable> DownloadData();
}

Клиентский код, который мы забыли поправить, тут же перестанет собираться, мы получим по рукам во время сборки продукта и сможем подумать, не погорячились ли мы с новым протоколом, или просто поправить клиента. Теперь понятно, как статически описать и проконтролировать альтернативные варианты workflow протокола?
Re[10]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 16.04.11 10:07
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Тогда упростим. Я подобный вопрос уже несколько раз задавал. От своего невежества, конечно. Только почему-то никто на него не ответил. Вот давай ответь.

Я тебя уже не первый год тыкаю носом в эту ссылку.
http://en.wikipedia.org/wiki/Dependent_type

Вот тебе ссылки про адаптацию этой теории для практики.
http://scholar.google.com/scholar?hl=ru&amp;q=type+refinements+programming&amp;btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA&amp;as_ylo=&amp;as_vis=0
Только ты же всеравно учиться не будешь.

PD>Ну вот я тебе пример привел выше, с минусом и корнем. Объясни просто и понятно, каким образом, не запуская программы, можно проверить правильность порядка вызова функций. Продемонстрируй свои знания в ответ на мое невежество.

Я тебе уже много всякого разного показывал но ты все проигнорировал.
Заниматься твоим образованием мне лень.
Ссылку я дал.
Читай.
Там более чем достаточно информации чтобы ты сам понял как сделать твой пример.

PD>Только, пожалуйста, останься в рамках предложенного ТС C#.


Я же говорю ты меня совсем не слушаешь.
В рамках C# это не решается. Тут как минимум type refinements нужны, а их в C# нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 16.04.11 10:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Nemerle тут может помочь только тем, что его код открыт и можно реализовать нужную функциональность в компиляторе. Но синтаксические навороты тут мало что дадут. Эта фича требует вмешательства в типизатор.

Хм. А как тебе следующий подход: метапрограмма, в самом общем виде — это программа которая обрабатывает другие программы. Помимо кодогенерации или трансформации она может заниматься и верификацией. Чисто теоретически легко себе представить макрос, который обходит AST программы, ищет все места использования типа, помеченного нужным атрибутом, и следит за тем, что бы выполнялись ограничения.
Re[20]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 16.04.11 10:11
Оценка:
Здравствуйте, adontz, Вы писали:

A>Значит эта система значительно примитивнее популярных систем.

Все там на месте. Просто ты не понял что это такое.

A>Вот не надо ля-ля. Вылизать можно тормоза в раза в два, а 50Мбит/с, это тормоза в 20 раз и это архитектурные проблемы.

Сам наблюдал ругонь человека который пилил файловую систему для линуха когда после очередного обновления девелоперской версии ядра производительность просела в разы.
Он долго сидел и искал что же там такого сделали что тормоза на ровном месте завелись.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 16.04.11 10:17
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Сколько еще лет тебе показывать эту ссылку?

WH>

WH>In computer science and logic, a dependent type is a type that depends on a value.

WH>http://en.wikipedia.org/wiki/Dependent_type
Справедливости ради надо сказать, что я зависимые типы изначально не думал применять
Мне кажется, что алгебраических типов с паттернматчингом вполне хватит для комфортной работы с такими протоколами.
Впрочем, раз уж зависимые типы упомянули, подумаю над их приложимостью к этой идее.
Re[10]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 16.04.11 10:27
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Справедливости ради надо сказать, что я зависимые типы изначально не думал применять

Я просто отвечал на вопрос Павла.

0>Мне кажется, что алгебраических типов с паттернматчингом вполне хватит для комфортной работы с такими протоколами.

0>Впрочем, раз уж зависимые типы упомянули, подумаю над их приложимостью к этой идее.
В твоей задаче они не особо нужны. Но с их помощью можно ее решить не напрягаясь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Интерфейс vs. протокол.
От: dotneter  
Дата: 16.04.11 11:49
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>ее с консоли введут.

Можно проще. Из консоли поступает строка, мы может либо продолжать работать со строкой, либо сделать проверку, потом int.Parse и наделим значение типом говорящим о том что это не просто строка а число, дальше можно продолжить и добавить в тип еще информацию о знаке и т.д.
Talk is cheap. Show me the code.
Re[10]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 16.04.11 15:15
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вот тебе простой пример...

Спору нет, применимость любой модели программирования ограничена и на роль серебряной пули я этот подход и не предлагал.
В простых сценариях я применял подобные вещи на практике с успехом (правда, не осознав до конца, что я делаю).
Как он покажет себя на более сложных — это вопрос, который нуждается в проверке практикой. Не замахиваясь на революцию, я вполне допускаю, что из этого может получится неплохой инструмент, облегчающий программирование некоторого класса задач.

PD>ИМХО все это чистый академизм, не имеющий отношения к реальной работе. Теоретизировать можно, а потом все это уйдет в архив вполне благополучно.

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

Если разбираться в причинах этого "академизма", то есть желание как можно больше аспектов программы выражать формальным образом, что бы компилятор мог статически доказывать корректность программы относительно этого аспекта. С другой стороны, это требует соответствующей теоретической базы, подготовки людей, поддержки со стороны языка и дополнительных затрат при программировании, то есть дается совсем не бесплатно. Где-то на балансе выигрыша и стоимости надо искать решение.
Re[13]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 16.04.11 15:36
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>По этой ссылке написано как это сделать.


PD>>То есть ты пополнил список тех, кому я этот вопрос задал и кто ответить так и не смог. Неудивительно.

WH>Ну разумеется.
WH>Если ответы тупо игнорируются...
WH>Ссылки я тебе дал.
WH>Если есть желание образовывайся.
WH>Если нет, то перестань бравировать своим невежеством. Не смешно уже.

Не смешно тебе, ну и не смейся. Мне от этого ни холодно, ни жарко. Когда мне кто-то объяснит (тупо, на пальцах, идею) всего этого, я ее оценю и решу, стоит ли мне этим вообще интересоваться. Пока же вижу одно — никто не в состоянии на мои примеры привести аргументы, которые дали бы мне такое основание.

А вообще все это так далеко от реальных моих нужд, как почившая вроде бы в бозе Сингуларити от Windows 7 или Linux.
With best regards
Pavel Dvorkin
Re[12]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 16.04.11 15:37
Оценка:
Здравствуйте, adontz, Вы писали:

A>Влад, как раз ты сейчас и балаболишь. вот у меня есть 1000 классов. И них 47 штук — stateful, а 953 stateless (как правило они ещё и immutable). То есть даже если этот метод распрекрасный и делает всё что только можно придумать, 47 классов это потолок его внедряемости.

Я, кстати, сам ещё не понял до конца, может быть ли протокол у stateless класса Я исключительно поддерживаю идею делать беспротокольные интерфейсы. Если у меня будет выбор сделать интерфейс без протокола или навернуть на него формализм описания протокола, то я однозначно выберу первый вариант.
Но иногда выбора нет и вот тогда...
Re[7]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 16.04.11 16:04
Оценка:
Здравствуйте, 0x7be, Вы писали:

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


VD>>Nemerle тут может помочь только тем, что его код открыт и можно реализовать нужную функциональность в компиляторе. Но синтаксические навороты тут мало что дадут. Эта фича требует вмешательства в типизатор.

0>Хм. А как тебе следующий подход: метапрограмма, в самом общем виде — это программа которая обрабатывает другие программы. Помимо кодогенерации или трансформации она может заниматься и верификацией. Чисто теоретически легко себе представить макрос, который обходит AST программы, ищет все места использования типа, помеченного нужным атрибутом, и следит за тем, что бы выполнялись ограничения.

AST тут мало, надо еще знать, что оно делает.
Представь, что у тебя функции твоего интерфейса вызываются по одной через цепочки из десятка других функций, которые сами по себе при этом могут зваться в циклах, по условиям (т.е. иногда могут и не зваться, или зваться для разных объектов) и т.д. и т.п. Тебе придется в твоем анализаторе воспроизвести почти всю логику программы, чтобы отследить всё везде.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[14]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 16.04.11 16:11
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Не смешно тебе, ну и не смейся. Мне от этого ни холодно, ни жарко. Когда мне кто-то объяснит (тупо, на пальцах, идею) всего этого, я ее оценю и решу, стоит ли мне этим вообще интересоваться. Пока же вижу одно — никто не в состоянии на мои примеры привести аргументы, которые дали бы мне такое основание.


Тебе объяснение на пальцах зависимых типов? Так его на RSDN уже несколько раз давали, поиск в руки
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[15]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 16.04.11 17:02
Оценка:
Здравствуйте, jazzer, Вы писали:

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


PD>>Не смешно тебе, ну и не смейся. Мне от этого ни холодно, ни жарко. Когда мне кто-то объяснит (тупо, на пальцах, идею) всего этого, я ее оценю и решу, стоит ли мне этим вообще интересоваться. Пока же вижу одно — никто не в состоянии на мои примеры привести аргументы, которые дали бы мне такое основание.


J>Тебе объяснение на пальцах зависимых типов? Так его на RSDN уже несколько раз давали, поиск в руки


Нет. Объяснение, каким образом может контролироваться правильность последовательности вызовов в моем примере

http://rsdn.ru/forum/philosophy/4236549.1.aspx
Автор: Pavel Dvorkin
Дата: 16.04.11


в compile-time.
With best regards
Pavel Dvorkin
Re[16]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 16.04.11 17:14
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Нет. Объяснение, каким образом может контролироваться правильность последовательности вызовов в моем примере

PD>http://rsdn.ru/forum/philosophy/4236549.1.aspx
Автор: Pavel Dvorkin
Дата: 16.04.11

PD>в compile-time.

Я правильно понимаю, что тебе, фактически, надо гарантировать, что sqrt не будет вызван для отрицательного числа?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[17]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 04:04
Оценка:
Здравствуйте, jazzer, Вы писали:

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


PD>>Нет. Объяснение, каким образом может контролироваться правильность последовательности вызовов в моем примере

PD>>http://rsdn.ru/forum/philosophy/4236549.1.aspx
Автор: Pavel Dvorkin
Дата: 16.04.11

PD>>в compile-time.

J>Я правильно понимаю, что тебе, фактически, надо гарантировать, что sqrt не будет вызван для отрицательного числа?


Нет. Мне доказывают, что можно сделать нечто, что позволит определить правильность порядка вызова функций без запуска программы, статически. Я привожу пример, когда ИМХО невозможно без запуска определить, правилен порядок или нет. Вот и все.
With best regards
Pavel Dvorkin
Re[18]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 17.04.11 06:40
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


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


PD>>>Нет. Объяснение, каким образом может контролироваться правильность последовательности вызовов в моем примере

PD>>>http://rsdn.ru/forum/philosophy/4236549.1.aspx
Автор: Pavel Dvorkin
Дата: 16.04.11

PD>>>в compile-time.

J>>Я правильно понимаю, что тебе, фактически, надо гарантировать, что sqrt не будет вызван для отрицательного числа?


PD>Нет. Мне доказывают, что можно сделать нечто, что позволит определить правильность порядка вызова функций без запуска программы, статически. Я привожу пример, когда ИМХО невозможно без запуска определить, правилен порядок или нет. Вот и все.


Ну, просто порядок вызовов статически определить не проблема, правильно? См. Boost.Proto, например.
Т.е. отталкиваемся от того, что порядок узнать мы можем и проверить его тоже можем (оставим пока за скобками то, что в этом примитивном случае у тебя проверяющий код будет сравним с самим кодом). Осталось только проверить, правильная ли версия выбирается в зависимости от знака аргумента. Для этого нужно знак вынести в тип (т.е. на выходе if должна быть не просто f, а Positive(f) для главной ветки и NonPositive(f) для ветки else) — это и есть зависимые типы:
struct Positive { float f; };
struct NonPositive { float f; };
// и т.д. для Negative, Zero и т.д.

Positive sqrt(Positive);
NonPositive minus(Positive);
Positive minus(NonPositive);

Здесь видно, что и minus(sqrt(Positive)), и minus(sqrt(minus(NonPositive))) даст NonPositive, а sqrt(NonPositive) просто не скомпилируется.

Управляющие структуры обычный С++ нетипизированы (в том смысле, как я написал выше). Поэтому придется написать свой if как-то так:
template <class Then, class Else>
void if_positive(float f, Then then_, Else else_)
{
  if (f>0) then_( Positive(f) ); else_( NonPositive(f) );
};

как видишь, теперь у нас рантайм-свойство переменной (знак) выражено в типе, и когда ты будешь звать if_positive и попробуешь передать ему sqrt в качестве else — программа не скомпилируется.

Идея понятна?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[19]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 09:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Нет. Мне доказывают, что можно сделать нечто, что позволит определить правильность порядка вызова функций без запуска программы, статически. Я привожу пример, когда ИМХО невозможно без запуска определить, правилен порядок или нет. Вот и все.

WH>Я тебе уже несколько лет привожу ссылки на статьи, где описаны и теория и практика.
WH>Даны все теоремы и их доказательства.
WH>Продемонстрированы работающие компиляторы, которые это делают на практике.
WH>Причем все статьи прошли рецензию и опубликованы в уважаемых изданиях.
WH>Все что нужно сделать, это прочитать статьи с включенным мозгом.
WH>А ты все не возможно да не возможно.
WH>Такое поведение называется воинствующее невежество.

Пока мне кто-нибудь не объяснит на пальцах, как можно разрулить ту ситуацию, которуя я описал, я не намерен тратить свое время на изучение этих теорем и работающих компиляторов с маргинальных языков. Это называется обыкновенным скептицизмом. Если кто-то мне скажет, что можно из воздуха получать золото, я сначала попрошу объяснить мне химию или физику этого процесса, и если объяснение будет удовлетворительным — только тогда займусь изучением сам. А до тех пор и с места не сдвинусь. Хорош бы я был, если бы последовал твоему совету несколько лет назад и начал всерьез интересоваться Сингуларити. Мне эта затея с самого начала показалась несерьезной, так оно и оказалось. Хотя и работающий прототип был, и запустить можно было.

простоя не намерен, как ребенок, бросаться на всякую новую игрушку. Много я этих игрушек видел — сначала шум до потолка, потом всеобщее забвение.

Ты объяснить не способен или не хочешь, ну и ладно. Сейчас jazzer пытается, посмотрим, что получится
With best regards
Pavel Dvorkin
Re[7]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.04.11 10:10
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Хм. А как тебе следующий подход: метапрограмма, в самом общем виде — это программа которая обрабатывает другие программы. Помимо кодогенерации или трансформации она может заниматься и верификацией. Чисто теоретически легко себе представить макрос, который обходит AST программы, ищет все места использования типа, помеченного нужным атрибутом, и следит за тем, что бы выполнялись ограничения.


AST для этого должно быть типизированным.

О том, что надо сделать в немерел я тут говорил где-то рядом. Нужно добавить пару событий в компилятор которые позволят вмешаться в процесс обработки типизированного АСТ на последних стадиях. Это не будет макросом, но конечно же будет похожим на них.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.04.11 10:14
Оценка:
Здравствуйте, jazzer, Вы писали:

J>>> (хотя математически сам компьютер — это КА, и соответственно все, что на нем работает, тоже КА),


VD>>Ой как интересно! С удовольствием послушаю о том какое состояние конечное у компьютера.

J>В школу. Конечность автомата относится к конечности множества состояний.

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

ЗЫ

Уровень данного разговора меня не удовлетворяет. Вернешься из школы, заходи еще раз.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 17.04.11 10:27
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Пока мне кто-нибудь не объяснит на пальцах, как можно разрулить ту ситуацию, которуя я описал, я не намерен тратить свое время на изучение этих теорем и работающих компиляторов с маргинальных языков. Это называется обыкновенным скептицизмом.

Нет. Это называется обыкновенным ламеризмом.
Есть теория.
Есть куча применений на практике.
Один Coq чего стоит. http://en.wikipedia.org/wiki/Coq
А ты даже пару небольший статей прочитать не можешь.
Да ты на этот флуд больше времене потратил.

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

Если бы ты читал то что тебе пишут то понял бы две вещи:
1)Сингулярити изначально была исследовательской работы и практического будущего не имела.
2)Я сам много ругался по поводу кучи глупостей которые натворили авторы сингулярити. Но им простительно. Они ученые, а не инженеры.

PD>Ты объяснить не способен или не хочешь, ну и ладно. Сейчас jazzer пытается, посмотрим, что получится

Я тебе объяснял кучу раз. Вот буквально только что.
Автор: WolfHound
Дата: 15.04.11

И каков результат?
Полный игнор всего сказанного.
Каков смысл тратить усилия на того кто даже не слушает?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.04.11 10:31
Оценка:
Здравствуйте, adontz, Вы писали:

WH>>ЛОЛ! Рома ты мне не поверишь но это просто альтернативный метод записать ДКА


A>Да, он называется НКА.


Ром, если у НКА объединить состояния, как это сделал ты, то как раз получится ДКА.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 17.04.11 10:38
Оценка:
Здравствуйте, VladD2, Вы писали:

A>>Да, он называется НКА.

VD>Ром, если у НКА объединить состояния, как это сделал ты, то как раз получится ДКА.

Я это где-то отрицал? Я лишь утверждаю, что изначально информация задаётся в виде НКА.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[18]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.04.11 10:41
Оценка:
Здравствуйте, adontz, Вы писали:

A>Сингуларити... дай вспомнить.... Веб-сервер в 8 раз медленее на там же железе, 50Мб/с — максимальная пропускная способность TCP/IP стека и твои уверения, что безопасность не влияет на скорость. Нет, не интересно.


Откуда дровишки? Мне припоминается, что как раз в большинстве тестов она работала на уровне лучших результатов. И это при явной непотимизированности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.04.11 10:44
Оценка:
Здравствуйте, adontz, Вы писали:

A>>>Сингуларити... дай вспомнить.... Веб-сервер в 8 раз медленее на там же железе, 50Мб/с — максимальная пропускная способность TCP/IP стека и твои уверения, что безопасность не влияет на скорость. Нет, не интересно.

WH>>Рома ты просто фееричен. Сравнивать вылизанную ОС и вылизанный веб сервер с экспериментальной системой...

A>Вот не надо ля-ля. Вылизать можно тормоза в раза в два, а 50Мбит/с, это тормоза в 20 раз и это архитектурные проблемы.


Ну, к примеру PegGrammar в релизе (с оптимизациями) где-то в 10 раз быстрее чем в дебаге (где оптимизации не используются). А если сравнивать его с ранними, неоптимизированными, версиями, то разница будет и по более. Так что 8 раз — это как раз совершенно реальный результат.

И все же. Откуда взята цифра 8?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 17.04.11 10:53
Оценка:
Здравствуйте, VladD2, Вы писали:

A>>Сингуларити... дай вспомнить.... Веб-сервер в 8 раз медленее на там же железе, 50Мб/с — максимальная пропускная способность TCP/IP стека и твои уверения, что безопасность не влияет на скорость. Нет, не интересно.

VD>Откуда дровишки? Мне припоминается, что как раз в большинстве тестов она работала на уровне лучших результатов. И это при явной непотимизированности.

Из статьи про сингуларити на этом сайте.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[21]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 17.04.11 10:53
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И все же. Откуда взята цифра 8?


Из статьи про сингуларити на этом сайте.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[20]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 17.04.11 11:17
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Но применимость такой идеи ничтожна, и по сути ограничивается именно таким примером, ну может, еще парочкой иных. А в том же примере с sqrt и положительными- неотрицательными и т.д. стоит лишь слегка его усложнить (например, разделить все множество не на 2 (положительные и неположительные), а, скажем, на 10-20 интервалов- и сразу вся эта затея превратится в необозримое чудовище. А если таких чудовищ будет с десяток (а это пустяки), то в этом хаосе уже никто не разберется. Я никак не могу поверить в серьезность подобной затеи.

Собственно твоя обычная реакция на все объяснения.
"Все фигня и на практике не применимо."
Самое забавное во всей этой истории, что jazzer зависимые типы не показал.
В полноценной системе этих ужасов, что ты тут напридумывал нет.
Но тебе же все равно.
Ты же не знания хочешь получить, а свою веру отстоять.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 11:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А ты даже пару небольший статей прочитать не можешь.


Не хочу.

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

WH>Если бы ты читал то что тебе пишут то понял бы две вещи:
WH>1)Сингулярити изначально была исследовательской работы и практического будущего не имела.
WH>2)Я сам много ругался по поводу кучи глупостей которые натворили авторы сингулярити. Но им простительно. Они ученые, а не инженеры.

PD>>Ты объяснить не способен или не хочешь, ну и ладно. Сейчас jazzer пытается, посмотрим, что получится

WH>Я тебе объяснял кучу раз. Вот буквально только что.
Автор: WolfHound
Дата: 15.04.11

WH>И каков результат?
WH>Полный игнор всего сказанного.
WH>Каков смысл тратить усилия на того кто даже не слушает?

Ну и не трать. Тебя заставляют ? Ты же влез в эту дискуссию и ответил на какое-то мое сообщение, а не я. Мне вообще с тобой дискутировать совсем не интересно.
With best regards
Pavel Dvorkin
Re[9]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 17.04.11 11:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Уровень данного разговора меня не удовлетворяет.


Меня тоже. На том и порешим. Спасибо, что предложил. С тобой все равно редко разговор конструктивным получается. К сожалению.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[20]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 17.04.11 11:59
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


PD>>>Нет. Мне доказывают, что можно сделать нечто, что позволит определить правильность порядка вызова функций без запуска программы, статически. Я привожу пример, когда ИМХО невозможно без запуска определить, правилен порядок или нет. Вот и все.


J>>Ну, просто порядок вызовов статически определить не проблема, правильно? См. Boost.Proto, например.

J>>Т.е. отталкиваемся от того, что порядок узнать мы можем и проверить его тоже можем (оставим пока за скобками то, что в этом примитивном случае у тебя проверяющий код будет сравним с самим кодом).

PD>Порядок чего ? Вызовов в рантайме ? Проверяющий код будет при этом не сравним с самим кодом, а просто равен ему. И ничего тут не поможет.

Зависит от задачи. Вот обсужадемый пример с файлом — проверочный код совсем не равен вызываемому.
http://www.rsdn.ru/forum/philosophy/4235576.1.aspx
Автор: jazzer
Дата: 15.04.11


PD>Вот пример, я его уже приводил

...
PD>Можно ли определить, какая функция будет вызвана : DoX или DoY без этого проведения этого итерационного процесса в полном объеме ? Если бы это было возможно, математики человеку, которое такое решение бы предложил, при жизни памятник поставили.

Ты сводишь разговор к абсурду. Есть вычисления времени компиляции, а есть — рантаймовые. Если компилятор достаточно продвинутый, то вообще всю работу программы можно перенести на время компиляции, так что результирующая программа просто будет содержать print 42.
Если ты хочешь вообще все перенести на время компиляции — твое право, но это не значит, что это — единственный способ их использования, правда?
Опять же, см. пример с файлом, ссылка выше.

А то разговор ни о чем получается, я тебе: "Есть задачи, которые можно решить вот так за линейное время", а ты мне: "А вот есть задача коммивояжера, ну-ка реши мне ее за линейное время, я тебе памятник поставлю тогда!"

PD>И в моем примере с sqrt вопрос не в том, должен ли быть аргумент sqrt положительным. Вопрос в другом — правильно ли я задал порядок действий.

PD>Тут все аргументы годятся , и этот код никаких исключений вызвать не должен. Но правильно ли я его написал ? Может, надо было написать if(x<0) ? И ты берешься в compile-time без тестирования сказать, правильно или нет ?
Чтобы определить, правильно ли ты задал порядок действий, тебе надо где-то этот правильный порядок действий описать, не?
Т.е. ты должен предъявить компилятору правильный порядок и актуальный, чтоб компилятор мог проверить.
Можно, как ты это делаешь, свести все к абсурду и дать компилятору правильную программу, а потом ее же еще раз, и попросить сравнить.
Ценность этой проверки будет равна нулю, очевидно, потому что сложность реализации эталона (и как следствие, ошибкоёмость) равна сложности написания самой программы, которая должна соответствовать этому эталону.
Подобные проверки имеет смысл делать, когда проверяющий код гораздо легче верифицировать, чем целевой код. В твоем примере они равны.

PD>Но применимость такой идеи ничтожна, и по сути ограничивается именно таким примером, ну может, еще парочкой иных.

В примере с WinAPI проверяется всего ничего, поэтому идея и работает. Ровно в соответствии с тем, что я сказал выше.
С тем же файлом — стоит задача не проверить вообще все, а только то, что некторые методы не вызываются до/после других.
Хотя, ессно, можно написать код, который верифицировать нельзя, типа вызывать все функции по рэндому.

PD>А в том же примере с sqrt и положительными- неотрицательными и т.д. стоит лишь слегка его усложнить (например, разделить все множество не на 2 (положительные и неположительные), а, скажем, на 10-20 интервалов- и сразу вся эта затея превратится в необозримое чудовище. А если таких чудовищ будет с десяток (а это пустяки), то в этом хаосе уже никто не разберется. Я никак не могу поверить в серьезность подобной затеи.


Ты веришь в Пролог? Или любой другой решатель логических систем? А теперь возьми язык, у которого подобный решатель встроен непосредственно в компилятор и есть средства задавать систему ограничений/отношений — и никакого хаоса не будет, как его нет в Прологе, хоть ты там сто интервалов сделай.
Естественно, это не С++ и прочие шарпы.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[10]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 17.04.11 12:00
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>
PD>class A{
PD> public float SqRoot(float f) {return sqrt(f);}
PD> public float Minus(float f) { return -f;}
PD> public float Func(float f)
PD> {
PD>   if(f < 0)
PD>    return Minus(SqRoot(f));
PD>   else
PD>    return SqRoot(Minus(f));
PD>}
PD>

PD>Меня сомнение гложет — в правильном порядке я функции вызываю или нет в Func ?. Может, надо было наоборот ? 2 теста в рантайме дадут вполне определенный ответ.
Этот пример несколько нерелевантен тому, что я предлагаю
Тут нет интерфейса с фиксированным протоколом, исполнение которого надо контролировать, соответственно нету относительно чего контролировать правильность вызовов. Естественно, что компилятор не может подсказать тебе, правильно ли ты вызываешь функции или нет.
Re[8]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 17.04.11 12:21
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>AST для этого должно быть типизированным.

Конечно.

VD>О том, что надо сделать в немерел я тут говорил где-то рядом. Нужно добавить пару событий в компилятор которые позволят вмешаться в процесс обработки типизированного АСТ на последних стадиях. Это не будет макросом, но конечно же будет похожим на них.

Я полагаю, что мы друг друга вполне поняли
Re[20]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.04.11 12:33
Оценка:
Здравствуйте, adontz, Вы писали:

A>>>Сингуларити... дай вспомнить.... Веб-сервер в 8 раз медленее на там же железе, 50Мб/с — максимальная пропускная способность TCP/IP стека и твои уверения, что безопасность не влияет на скорость. Нет, не интересно.

VD>>Откуда дровишки? Мне припоминается, что как раз в большинстве тестов она работала на уровне лучших результатов. И это при явной непотимизированности.

A>Из статьи про сингуларити на этом сайте.


А можно цитату?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.04.11 12:34
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Меня тоже. На том и порешим. Спасибо, что предложил. С тобой все равно редко разговор конструктивным получается. К сожалению.


Да уж.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 12:59
Оценка:
Здравствуйте, jazzer, Вы писали:

PD>>Порядок чего ? Вызовов в рантайме ? Проверяющий код будет при этом не сравним с самим кодом, а просто равен ему. И ничего тут не поможет.

J>Зависит от задачи. Вот обсужадемый пример с файлом — проверочный код совсем не равен вызываемому.
J>http://www.rsdn.ru/forum/philosophy/4235576.1.aspx
Автор: jazzer
Дата: 15.04.11


Да, я это уже видкл. Твой подход с КА мне кажется верным.

PD>>Вот пример, я его уже приводил

J>...
PD>>Можно ли определить, какая функция будет вызвана : DoX или DoY без этого проведения этого итерационного процесса в полном объеме ? Если бы это было возможно, математики человеку, которое такое решение бы предложил, при жизни памятник поставили.

J>Ты сводишь разговор к абсурду. Есть вычисления времени компиляции, а есть — рантаймовые. Если компилятор достаточно продвинутый, то вообще всю работу программы можно перенести на время компиляции, так что результирующая программа просто будет содержать print 42.

J>Если ты хочешь вообще все перенести на время компиляции — твое право, но это не значит, что это — единственный способ их использования, правда?
J>Опять же, см. пример с файлом, ссылка выше.

Согласен. Я ведь простую вещь говорю. Разумееется, есть случаи, когда можно вынести эту проверку на этап компиляции. Но ИМХО это возможно при очень простой, чтобы не сказать примитивной логике задачи. Как только что-то посложнее — так сразу и не подходит. Я не против того, что иногда это может быть работоспособным, но едва ли ради этого надо огород городить. Если при сложной логике мы в рантайме все же разберемся, правильно или нет вызвали методы, то почему для простой логики надо это в компиле-тайм переносить, да еще при этом то ли новый язык создавать, то ли старый изменять. Чуть усложнится логика и все равно все прахом пойдет — у КА будет столько состояний, что никакой анализ в компиле-тайм не будет реально возможным.

J>А то разговор ни о чем получается, я тебе: "Есть задачи, которые можно решить вот так за линейное время", а ты мне: "А вот есть задача коммивояжера, ну-ка реши мне ее за линейное время, я тебе памятник поставлю тогда!"


Верно.

J>Чтобы определить, правильно ли ты задал порядок действий, тебе надо где-то этот правильный порядок действий описать, не?

J>Т.е. ты должен предъявить компилятору правильный порядок и актуальный, чтоб компилятор мог проверить.

Ха! В том-то и дело. И это описание в сложном случае будет эквивалентно рантаймовскому исполнению. Вот возьми мой пример с итерацией. Описать прравило вызова DoX или DoY ? Пожалуйста. Если результат итерации > 0 — DoX, иначе DoY. И получаем перенос итерации в компиле-тайм. Да еще зависимость от всех возможных f .


J>Можно, как ты это делаешь, свести все к абсурду и дать компилятору правильную программу, а потом ее же еще раз, и попросить сравнить.

J>Ценность этой проверки будет равна нулю, очевидно, потому что сложность реализации эталона (и как следствие, ошибкоёмость) равна сложности написания самой программы, которая должна соответствовать этому эталону.

Именно. Я об этом и говорю.

J>Подобные проверки имеет смысл делать, когда проверяющий код гораздо легче верифицировать, чем целевой код. В твоем примере они равны.


См. выше.

J>В примере с WinAPI проверяется всего ничего, поэтому идея и работает. Ровно в соответствии с тем, что я сказал выше.

J>С тем же файлом — стоит задача не проверить вообще все, а только то, что некторые методы не вызываются до/после других.
J>Хотя, ессно, можно написать код, который верифицировать нельзя, типа вызывать все функции по рэндому.

И не только по рандому. При достаточно сложной логике, при логике, зависящей от исходных данных — в общем случае тоже нельзя. Вот ты пример с файлом привел. А если я его модифицирую, вспомнив про права доступа. Мол, если не открыли с Full Access, то открыть с Read Only, а тогда, естественно, не писать, а писать все же надо, а для этого придется завести другой файл в другом каталоге, а там опять возможен Access Denied и т.д.

PD>>А в том же примере с sqrt и положительными- неотрицательными и т.д. стоит лишь слегка его усложнить (например, разделить все множество не на 2 (положительные и неположительные), а, скажем, на 10-20 интервалов- и сразу вся эта затея превратится в необозримое чудовище. А если таких чудовищ будет с десяток (а это пустяки), то в этом хаосе уже никто не разберется. Я никак не могу поверить в серьезность подобной затеи.


J>Ты веришь в Пролог? Или любой другой решатель логических систем?


Я верю (как я могу не верить!) в его существование, но я помню при этом, что т.н. вызов Японии миру (проект ЭВМ 5 поколения 80-х годов), напрочь провалившийся, намертво связан с Прологом. Не очень у него хорошая репутация.

>А теперь возьми язык, у которого подобный решатель встроен непосредственно в компилятор и есть средства задавать систему ограничений/отношений — и никакого хаоса не будет, как его нет в Прологе, хоть ты там сто интервалов сделай.


Боюсь, что применение этого решателя в компиляторе будет эквивалентно выполнению этой программы в рантайме. Ты меня в ad absurdum обвинил, ну а раз так, устрою я и впрямь ad absurdum. Берем чисто интерпретируемый язык, например, классический Бейсик, но расширенный синтаксический до приличного состояния. Где тут compile-time и где run-time ? Нет их. Есть time исполнения. И в рамках его и получится, что интерпретатор будет определять порядок действий (интерпретатор!), в зависимости от того, что он раньше проинтерпретировал. Весть процесс выполнения прогрмммы и есть эта самая интерпретация


J>Естественно, это не С++ и прочие шарпы.
With best regards
Pavel Dvorkin
Re[23]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 13:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>ЧТД.

WH>Ты сюда пришёл не за знаниями, а для того чтобы свою веру отстаивать.

Точнее , для того, чтобы высказывать свою точку зрения, даже если она не совпадает с чьей-то иной или даже лбщепринятой.

PD>>Ну и не трать. Тебя заставляют ? Ты же влез в эту дискуссию и ответил на какое-то мое сообщение, а не я. Мне вообще с тобой дискутировать совсем не интересно.

WH>А я не на тебя время трачу.
WH>Проблема в том, что воинствующий невежда, уверенный в своей правоте может просто передавить нормальных людей с недостатком знаний.

Добродетель, которая нуждается в защите, едва ли стоит того, чтобы ее защищать. (С) не помню чей.

WH>А это уже прямой вред посетителям сайта.


Какая трогательная забота о посетителях! Ну тогда продолжай ее и дальше.
With best regards
Pavel Dvorkin
Re[11]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 13:05
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>
PD>>class A{
PD>> public float SqRoot(float f) {return sqrt(f);}
PD>> public float Minus(float f) { return -f;}
PD>> public float Func(float f)
PD>> {
PD>>   if(f < 0)
PD>>    return Minus(SqRoot(f));
PD>>   else
PD>>    return SqRoot(Minus(f));
PD>>}
PD>>

PD>>Меня сомнение гложет — в правильном порядке я функции вызываю или нет в Func ?. Может, надо было наоборот ? 2 теста в рантайме дадут вполне определенный ответ.
0>Этот пример несколько нерелевантен тому, что я предлагаю
0>Тут нет интерфейса с фиксированным протоколом, исполнение которого надо контролировать, соответственно нету относительно чего контролировать правильность вызовов. Естественно, что компилятор не может подсказать тебе, правильно ли ты вызываешь функции или нет.

Хорошо. Тогда так

if(bool)
{
Open;
Read;
Close;
}
else
{
Read;
Close;
Open;
}

Можно оценить правильность в общем случае ?
With best regards
Pavel Dvorkin
Re[21]: Интерфейс vs. протокол.
От: adontz Грузия http://adontz.wordpress.com/
Дата: 17.04.11 13:13
Оценка:
Здравствуйте, VladD2, Вы писали:

http://www.rsdn.ru/article/singularity/singularity.xml
Автор(ы): Galen Hunt, James Larus, Martin Abadi, Mark Aiken, Paul Barham, Manuel Fahndrich, Chris Hawblitzel, Orion Hodson, Steven Levi, Nick Murphy, Bjarne Steensgaard, David Tarditi, Ted Wobber, Brian Zill
Дата: 02.03.2006
Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?


Singularity выдала 91 операцию в секунду при взвешенной средней пропускной способности в 362 Kбит/с. Web-сервер IIS, выполняемый под управлением Windows 2003 на идентичной аппаратуре, выдает 761 операцию в секунду при взвешенной средней пропускной способности в 336 Kбит/с.


Сетевой стек Singularity, наоборот, не является узким местом, и может поддерживать пропускную способность в 48Mбит/сек.


Статья старая, но даже по тогдашним меркам производительность просто нелепая. В обсуждении (не очень большом) это обсосано.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[22]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 17.04.11 13:25
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

(поскипал то, в чем мы оба согласны)

PD>Ха! В том-то и дело. И это описание в сложном случае будет эквивалентно рантаймовскому исполнению.

Ирония в том, что в чрезмерно простых случаях они тоже будут эквивалентны.

PD>Вот возьми мой пример с итерацией. Описать прравило вызова DoX или DoY ? Пожалуйста. Если результат итерации > 0 — DoX, иначе DoY. И получаем перенос итерации в компиле-тайм. Да еще зависимость от всех возможных f .


Нет, тут же у тебя один и тот же код, так что достаточно того, что скомпилируется мой if_positive из предыдущего письма. А вот если у тебя правило "функция всегда должна находить правильный корень" — тогда да, придется все вынести в компиляцию.

PD>При достаточно сложной логике, при логике, зависящей от исходных данных — в общем случае тоже нельзя.


Да в общем случае ничего нельзя В общем случае задача останова не решаема
Только нас интересеют не общий случай, а вполне конкретные частные.
И все разнообразие методов и подходов в программировании лежит именно в разнообразии частностей.
А зависимость от исходных данных — ну так она у меня есть, в виде знака этих самых исходных данных.

J>>Ты веришь в Пролог? Или любой другой решатель логических систем?


PD>Я верю (как я могу не верить!) в его существование, но я помню при этом, что т.н. вызов Японии миру (проект ЭВМ 5 поколения 80-х годов), напрочь провалившийся, намертво связан с Прологом. Не очень у него хорошая репутация.


Слушай, при твоем опыте программирования, и обвинять в неудаче проекта (причем уровня "вызов миру") язык?

>>А теперь возьми язык, у которого подобный решатель встроен непосредственно в компилятор и есть средства задавать систему ограничений/отношений — и никакого хаоса не будет, как его нет в Прологе, хоть ты там сто интервалов сделай.


PD>Боюсь, что применение этого решателя в компиляторе будет эквивалентно выполнению этой программы в рантайме.

Это всецело зависит от того, сколько ты хочешь отдать компилятору на контроль. Если всю программу — тогда да, будет вся программа.
Как и везде, нужен баланс.

ЗЫ. Мой учитель по вычматам любил говорить, что для большинства интересных численных моделей строгое обоснование модели эквивалентно аналитическому решению самой исходной задачи.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[20]: Интерфейс vs. протокол.
От: dotneter  
Дата: 17.04.11 13:34
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD> а, скажем, на 10-20 интервалов- и сразу вся эта затея превратится в необозримое чудовище. А если таких чудовищ будет с десяток (а это пустяки), то в этом хаосе уже никто не разберется. Я никак не могу поверить в серьезность подобной затеи.

Если на каждый чих делать по типу, то наверное да, а если можно будет создавать анонимные типы с ограничениями?
float[<0] Minus(float[>0] f)
Получили что то похожее на компилятора френдли контракты. Или вы в пользу DbC тоже не верите?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[23]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 13:44
Оценка:
Здравствуйте, jazzer, Вы писали:


PD>>Ха! В том-то и дело. И это описание в сложном случае будет эквивалентно рантаймовскому исполнению.

J>Ирония в том, что в чрезмерно простых случаях они тоже будут эквивалентны.

+1

J>>>Ты веришь в Пролог? Или любой другой решатель логических систем?


PD>>Я верю (как я могу не верить!) в его существование, но я помню при этом, что т.н. вызов Японии миру (проект ЭВМ 5 поколения 80-х годов), напрочь провалившийся, намертво связан с Прологом. Не очень у него хорошая репутация.


J>Слушай, при твоем опыте программирования, и обвинять в неудаче проекта (причем уровня "вызов миру") язык?


А я и не обвинял. Просто уж так получилось, что он намертво связан с этим провалившимся проектом. То ли он украл, то ли у него украли...


>>>А теперь возьми язык, у которого подобный решатель встроен непосредственно в компилятор и есть средства задавать систему ограничений/отношений — и никакого хаоса не будет, как его нет в Прологе, хоть ты там сто интервалов сделай.


PD>>Боюсь, что применение этого решателя в компиляторе будет эквивалентно выполнению этой программы в рантайме.

J>Это всецело зависит от того, сколько ты хочешь отдать компилятору на контроль. Если всю программу — тогда да, будет вся программа.
J>Как и везде, нужен баланс.

J>ЗЫ. Мой учитель по вычматам любил говорить, что для большинства интересных численных моделей строгое обоснование модели эквивалентно аналитическому решению самой исходной задачи.


Именно. Можно и другие примеры предложить.
With best regards
Pavel Dvorkin
Re[21]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 13:48
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>> а, скажем, на 10-20 интервалов- и сразу вся эта затея превратится в необозримое чудовище. А если таких чудовищ будет с десяток (а это пустяки), то в этом хаосе уже никто не разберется. Я никак не могу поверить в серьезность подобной затеи.

D>Если на каждый чих делать по типу, то наверное да, а если можно будет создавать анонимные типы с ограничениями?
D>float[<0] Minus(float[>0] f)

А давай типы с ограничениями. Паскаль беру потому, что они у него есть


type t_0_100 = 1..100;
type t_101_200 = 101..200;
type t_201_300 = 201..300;
type t_301_400 = 301..400;
// etc.


Выглядит симпатично. Например, температура воды должна быть в типе t_0_100, а некоего другого вещества- скажем, t_101_200. И т.д. Пока эти вещества сами по себе — все замечательно. Но однажды понадобится их раствор, а у него, скажем 25..180. И горело все это синим пламенем.
With best regards
Pavel Dvorkin
Re[22]: Интерфейс vs. протокол.
От: dotneter  
Дата: 17.04.11 13:51
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


D>>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>> а, скажем, на 10-20 интервалов- и сразу вся эта затея превратится в необозримое чудовище. А если таких чудовищ будет с десяток (а это пустяки), то в этом хаосе уже никто не разберется. Я никак не могу поверить в серьезность подобной затеи.

D>>Если на каждый чих делать по типу, то наверное да, а если можно будет создавать анонимные типы с ограничениями?
D>>float[<0] Minus(float[>0] f)

PD>А давай типы с ограничениями. Паскаль беру потому, что они у него есть



PD>
PD>type t_0_100 = 1..100;
PD>type t_101_200 = 101..200;
PD>type t_201_300 = 201..300;
PD>type t_301_400 = 301..400;
PD>// etc.
PD>


PD>Выглядит симпатично. Например, температура воды должна быть в типе t_0_100, а некоего другого вещества- скажем, t_101_200. И т.д. Пока эти вещества сами по себе — все замечательно. Но однажды понадобится их раствор, а у него, скажем 25..180. И горело все это синим пламенем.

Не совсем ясно в чем проблема, можно конкретную задачу с кодом?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[23]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 17.04.11 14:01
Оценка:
Здравствуйте, dotneter, Вы писали:

PD>>Выглядит симпатично. Например, температура воды должна быть в типе t_0_100, а некоего другого вещества- скажем, t_101_200. И т.д. Пока эти вещества сами по себе — все замечательно. Но однажды понадобится их раствор, а у него, скажем 25..180. И горело все это синим пламенем.

D>Не совсем ясно в чем проблема, можно конкретную задачу с кодом?
Ты попался на то о чем я написал тут
Автор: WolfHound
Дата: 17.04.11
.
В паскале нет зависимых типов. Как следствие все что сказал Павел идет в топку.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 17.04.11 14:19
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Хорошо. Тогда так

PD>if(bool)
PD> {
PD> Open;
PD> Read;
PD> Close;
PD>}
PD>else
PD>{
PD> Read;
PD> Close;
PD> Open;
PD>}
PD>Можно оценить правильность в общем случае ?

Да, только я не понимаю, в чем тут смысл ветвления.
Выглядеть это будет примерно так:
var service = GetService();
if(bool)
{
  service
   .Open()
   .Read()
   .Close();
}
else
{
  service
   .Read() // Ошибка компиляции, тип ссылки service не содержит метода Read.
   .Close()
   .Open();
}
Re[23]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 14:50
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, Pavel Dvorkin, Вы писали:


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


D>>>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>>> а, скажем, на 10-20 интервалов- и сразу вся эта затея превратится в необозримое чудовище. А если таких чудовищ будет с десяток (а это пустяки), то в этом хаосе уже никто не разберется. Я никак не могу поверить в серьезность подобной затеи.

D>>>Если на каждый чих делать по типу, то наверное да, а если можно будет создавать анонимные типы с ограничениями?
D>>>float[<0] Minus(float[>0] f)

PD>>А давай типы с ограничениями. Паскаль беру потому, что они у него есть



PD>>
PD>>type t_0_100 = 1..100;
PD>>type t_101_200 = 101..200;
PD>>type t_201_300 = 201..300;
PD>>type t_301_400 = 301..400;
PD>>// etc.
PD>>


PD>>Выглядит симпатично. Например, температура воды должна быть в типе t_0_100, а некоего другого вещества- скажем, t_101_200. И т.д. Пока эти вещества сами по себе — все замечательно. Но однажды понадобится их раствор, а у него, скажем 25..180. И горело все это синим пламенем.

D>Не совсем ясно в чем проблема, можно конкретную задачу с кодом?

Типы , описанные выше, будем считать существующими

procedure GetMixtureBoilingPoint(water percent, other_percent) : T
{
  // код, вычисляющий температуру кипения этой смеси. В зависимости от процентов будет от 25 до 180)
}


Определи T
With best regards
Pavel Dvorkin
Re[25]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 14:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Точнее , для того, чтобы высказывать свою точку зрения, даже если она не совпадает с чьей-то иной или даже лбщепринятой.

WH>О чем я и говорю.
WH>Ты пропагандируешь свою веру.
WH>При этом игнорируя сотни статей в рецинзируемых журналах.

Я много чего игнорирую. И факт рецензирования где бы то ни было для меня небольшой аргумент. Я все же научный сотрудник по образованию, а если бы научные сотрудники принимали в качестве вргумента то, что это где-то опубликовано и прорецензировано, наука превратилась бы в коллекцию мусора.

PD>>Добродетель, которая нуждается в защите, едва ли стоит того, чтобы ее защищать. (С) не помню чей.

WH>Это бред полнейший.

Ну-ну... Аргументация, вполне достойная тебя.

PD>>Какая трогательная забота о посетителях! Ну тогда продолжай ее и дальше.

WH>Обязательно.

Давай. Мое воспитание не позволяет мне не отвечать, когда ко мне обращаются, так что у тебя есть полная возможность использовать этот мой недостаток. Но оно вполне позволяет отвечать сколь угодно резко, разумееется, в рамках общепринятой морали и правил RSDN.
With best regards
Pavel Dvorkin
Re[13]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 14:59
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Да, только я не понимаю, в чем тут смысл ветвления.

0>Выглядеть это будет примерно так:
0>
0>var service = GetService();
0>if(bool)
0>{
0>  service
0>   .Open()
0>   .Read()
0>   .Close();
0>}
0>else
0>{
0>  service
0>   .Read() // Ошибка компиляции, тип ссылки service не содержит метода Read.

Ну и зря он мне сообщает об ошибке. Дело в том, что при bool==false файл уже открыт, так как раньше (в совсем другом месте) пришлось выполнить предварительное чтение, а поэтому я решил, что не стоит файл закрывать, ибо знаю, что основное чтение делать вскоре придется - незачем тратить время на его закрытие и открытие заново.

0>   .Close()
0>   .Open();
0>}
0>
With best regards
Pavel Dvorkin
Re[25]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 15:00
Оценка:
Здравствуйте, jazzer, Вы писали:

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


PD>>А я и не обвинял. Просто уж так получилось, что он намертво связан с этим провалившимся проектом. То ли он украл, то ли у него украли...


J>


J>>>ЗЫ. Мой учитель по вычматам любил говорить, что для большинства интересных численных моделей строгое обоснование модели эквивалентно аналитическому решению самой исходной задачи.


PD>>Именно. Можно и другие примеры предложить.


J>Ну вот. Но это же не значит, что численные методы плохи или что им нет полезных применений


Эк тебя

За дискуссию спасибо. В общем, это примерно то, чего я и хотел от своих оппонентов. Внятно, четко и без демагогии и обвинений.
With best regards
Pavel Dvorkin
Re[24]: Интерфейс vs. протокол.
От: dotneter  
Дата: 17.04.11 15:11
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Определи T

type T = 25..180 ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[26]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 17.04.11 15:15
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я много чего игнорирую. И факт рецензирования где бы то ни было для меня небольшой аргумент. Я все же научный сотрудник по образованию, а если бы научные сотрудники принимали в качестве вргумента то, что это где-то опубликовано и прорецензировано, наука превратилась бы в коллекцию мусора.

Это как минимум повод прочитать.
Ты не сделал даже этого.

PD>Ну-ну... Аргументация, вполне достойная тебя.

Я называю вещи своими именами.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 15:17
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Определи T

D>type T = 25..180 ?

Именно. Немного усложнив ситуацию (я ведь и без того там еще 2 типа определил) и занявшись тройными системами, мы дойдем до полного хаоса.
With best regards
Pavel Dvorkin
Re[27]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 17.04.11 15:24
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Я много чего игнорирую. И факт рецензирования где бы то ни было для меня небольшой аргумент. Я все же научный сотрудник по образованию, а если бы научные сотрудники принимали в качестве вргумента то, что это где-то опубликовано и прорецензировано, наука превратилась бы в коллекцию мусора.

WH>Это как минимум повод прочитать.
WH>Ты не сделал даже этого.

Я же объяснил почему. Кстати, из дискуссии с jazzer все вполне выяснилось. Мое мнение осталось примерно тем же, что и было — применимо в некоторых простых случаях, для более сложных — неприменимо или столь усложнено, что попытка применить эквивалентна переносу рантайма в компиле-тайм. Так что для случаев, когда заведомо известно, что все будет не просто, а очень просто (вроде open-read-close, и ни шагу влево или вправо!) это может быть применимо, ну а если шаги вправо-влево хотя бы в принципе допустимы, то в итоге потратишь времени больше, чем если бы этим не заниматься.


PD>>Ну-ну... Аргументация, вполне достойная тебя.

WH>Я называю вещи своими именами.

Только вот , еще раз, эта фраза не моя. Кажется, Маркса. Она довольно-таки хорошо известна. И твое отнесение ее к бреду выглядит, право слово, довольно комично, тем более без всякой аргументации.
With best regards
Pavel Dvorkin
Re[14]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 17.04.11 15:25
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну и зря он мне сообщает об ошибке. Дело в том, что при bool==false файл уже открыт, так как раньше (в совсем другом месте) пришлось выполнить предварительное чтение, а поэтому я решил, что не стоит файл закрывать, ибо знаю, что основное чтение делать вскоре придется — незачем тратить время на его закрытие и открытие заново.

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

Касаемо новых условий примера, вот решение:
var service = GetSerive();

Optional<IMyFileRead> readService;

// Первая возможность открыть файл.
if(условие предварительного чтения)
{
  readService = service.Open();     // Открываем файл.
  readService = readService.Read(); // Читаем предварительно.
}

...

// Вторая возможность открыть файл.
if(!readService.HasValue) // Определяем, что файл раньше не открывался.
{
  readService = service.Open();  // Открываем файл, если раньше не открывался.
}

// Основная работа с сервисом.
readService = readService.Read(); // Читаем.
readService.Close();              // Закрываем.
Re[26]: Интерфейс vs. протокол.
От: dotneter  
Дата: 17.04.11 15:32
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


D>>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>>Определи T

D>>type T = 25..180 ?

PD>Именно. Немного усложнив ситуацию (я ведь и без того там еще 2 типа определил) и занявшись тройными системами, мы дойдем до полного хаоса.

Таr я же и написал что можно типы не определять

procedure GetMixtureBoilingPoint(float[0..1] percent, float[0..1] other_percent) : float[25..180]
{

}
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[28]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 17.04.11 15:47
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я же объяснил почему.

Ты сказал "нехочу".

PD>Кстати, из дискуссии с jazzer все вполне выяснилось.

Учитывая что jazzer не показал зависимых типов...

PD>Мое мнение осталось примерно тем же, что и было — применимо в некоторых простых случаях, для более сложных — неприменимо или столь усложнено, что попытка применить эквивалентна переносу рантайма в компиле-тайм. Так что для случаев, когда заведомо известно, что все будет не просто, а очень просто (вроде open-read-close, и ни шагу влево или вправо!) это может быть применимо, ну а если шаги вправо-влево хотя бы в принципе допустимы, то в итоге потратишь времени больше, чем если бы этим не заниматься.

Для того чтобы понять нужно читать первоисточники, а не то что наплел jazzer.

PD>Только вот , еще раз, эта фраза не моя. Кажется, Маркса. Она довольно-таки хорошо известна. И твое отнесение ее к бреду выглядит, право слово, довольно комично, тем более без всякой аргументации.

Аппеляция к авторитету со стороны "научного сотрудника"
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 17.04.11 16:06
Оценка:
Здравствуйте, 0x7be, Вы писали:

PD>>Ну и зря он мне сообщает об ошибке. Дело в том, что при bool==false файл уже открыт, так как раньше (в совсем другом месте) пришлось выполнить предварительное чтение, а поэтому я решил, что не стоит файл закрывать, ибо знаю, что основное чтение делать вскоре придется — незачем тратить время на его закрытие и открытие заново.

0>Предлагаю на будущее сразу формулировать условие задачи целиком, что бы таких роялей в кустах не появлялось. Намного облегчит общение.
А он всегда так делает.
Причем что самое интересно он считает, что подобная логика организации программы совершенно нормальна.
Еще веселее то, что этот пример абсолютно искусственный, и он не знает, зачем это ему нужно.
А если из него таки вытащить реальное условие задачи, то выясняется что можно сделать намного проще.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 17.04.11 16:15
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Причем что самое интересно он считает, что подобная логика организации программы совершенно нормальна.

WH>Еще веселее то, что этот пример абсолютно искусственный, и он не знает, зачем это ему нужно.
WH>А если из него таки вытащить реальное условие задачи, то выясняется что можно сделать намного проще.
Ну, на практике всякое случается, иногда приходится делать через Ж. По разным причинам, техническим, историческим.
Но изменять условия задачи по ходу обсуждения все же не стоит.
Re[17]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 17.04.11 17:03
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Ну, на практике всякое случается, иногда приходится делать через Ж. По разным причинам, техническим, историческим.

У меня много чего было.
Но такого чтобы я не знал, открыт у меня файл или нет небыли ни разу.
Я даже не могу придумать ситуацию, в которой такое может произойти.

0>Но изменять условия задачи по ходу обсуждения все же не стоит.

Это его обычная тактика.
Вот тут
Автор: WolfHound
Дата: 15.04.11
я сделал не возможное.
Что сделал он?
Сменил задачу, полностью проигнорировав ответ.
Я же говорю, он сюда свою веру пришёл пропагандировать, а не знания получить.
Он этой фигней уже не первый год занимается.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 17.04.11 17:06
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Я же говорю, он сюда свою веру пришёл пропагандировать, а не знания получить.

WH>Он этой фигней уже не первый год занимается.
А в чем его вера заключается?
Re[19]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 17.04.11 17:50
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>А в чем его вера заключается?

Если коротко то:
Все кроме С++ говно!
В мире есть только императив!
Функциональщина академическое говно!
Всем нужно только С++ и WinAPI!
Производительность нужна любой ценой!
Надежность никому не нужна!
Краткость и понятность кода тоже ни кому не нужны! Тем более что производительность нужна любой ценой!
И вообще по памяти проезжаются только ламеры, а он великий гений программирования и никогда не допускает уязвимостей в своих программах!

То, что за прошедшие годы по всем пунктам его многократно тыкали носом в его ошибки, думаю и так понятно...
В ответ был либо полный игнор либо пафос что мы тут все ламеры которые только и могут что сайты заборостроительных компаний делать.
А если вдруг кому-то из нас дать сделать сайт уровня мелкософт.ком то мы завалим проект с треском.
После того как выяснилось что я в Яндексе работал он как-то сразу перестал вспоминать про сайты...
Это было бы весело если бы он не был профессором. Бедные студенты.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 17.04.11 23:33
Оценка:
Здравствуйте, vdimas, Вы писали:

V>От монады maybe можно смело отказываться при наличии нормального механизма исключений. Здесь чтение в buffer2 не покатит, если во время операции чтения в buffer мы не сохранили file, ведь при передаче параметра в read() мы потеряли владение ссылкой.


он не покатит в рантайме, а во время компиляции все хорошо будет.
А 0x7be хочет, чтобы вторая строчка не компилировалась.
Поправь, если не так.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[27]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 18.04.11 02:11
Оценка:
Здравствуйте, dotneter, Вы писали:

PD>>Именно. Немного усложнив ситуацию (я ведь и без того там еще 2 типа определил) и занявшись тройными системами, мы дойдем до полного хаоса.

D>Таr я же и написал что можно типы не определять

D>procedure GetMixtureBoilingPoint(float[0..1] percent, float[0..1] other_percent) : float[25..180]

D>{

D>}


А теперь представь себе, что мне нужно по процентам двухкомпонентной смеси любого состава определить точку кипения смеси (эх, если бы это было возможно — нет такого способа расчета). И получишь ты в итоге float[-273..5000], то есть просто float.
With best regards
Pavel Dvorkin
Re: Интерфейс vs. протокол.
От: ArtDenis Россия  
Дата: 18.04.11 03:12
Оценка:
Идея хорошая. Надо взять на заметку.
Из минусов вижу, что иногда протокол может быть настолько сложным, что его соблюдение невозможно будет контролировать в compile time. Но возможно, что это повод разбить протокол на несколько независимых уровней.
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[20]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 18.04.11 04:30
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Народ... Тема не об этом.

К сожелению об этом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[29]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 18.04.11 05:00
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>А теперь представь себе, что мне нужно по процентам двухкомпонентной смеси любого состава определить точку кипения смеси (эх, если бы это было возможно — нет такого способа расчета). И получишь ты в итоге float[-273..5000], то есть просто float.

WH>Ты либо крестик сними, либо трусы надень.

На таком уровне я с тобой дискуссию продолжать не намерен. Научись для начала себя вести как следует.
With best regards
Pavel Dvorkin
Re[16]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 18.04.11 05:04
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD><skipped>


PD>В том-то и дело, что этот рояль в кустах по ходу разработки появился как черт из табакерки. Не планировал я вначале никакого предварительного чтения, а потом вдруг выяснилось, что оно необходимо. Ты исправил решение на его слуай, а завтра что-то еще изменится. Без этих контрактов вставлю я дополнительные Open, Read, Close и проверю в рантайме тестами работу. А тебе придется на каждый случай модифицировать многое.

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

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

Да, именно так, я предлагаю перенести в статик часть того, что раньше жило только в динамике.
Согласен, тут есть свои пределы, как теоретические, так и практические.
Твердо убежден, что если за разумную цену можно заставить компилятор что-то за меня контролировать, то это лучше сделать.
Re[20]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 18.04.11 05:05
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Народ... Тема не об этом.

Ты прав, завязываю.
Re[30]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 18.04.11 05:19
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>На таком уровне я с тобой дискуссию продолжать не намерен. Научись для начала себя вести как следует.

Ответить по существу в очередной раз не в состоянии. Так и запишем.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 18.04.11 05:22
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Да, именно так, я предлагаю перенести в статик часть того, что раньше жило только в динамике.

0>Согласен, тут есть свои пределы, как теоретические, так и практические.
0>Твердо убежден, что если за разумную цену можно заставить компилятор что-то за меня контролировать, то это лучше сделать.

Боюсь, что в серьезных задачах цена будет очень высокой.
With best regards
Pavel Dvorkin
Re[31]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 18.04.11 05:23
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>На таком уровне я с тобой дискуссию продолжать не намерен. Научись для начала себя вести как следует.

WH>Ответить по существу в очередной раз не в состоянии. Так и запишем.

Провокациями занялся ? Ну-ну.
With best regards
Pavel Dvorkin
Re[32]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 18.04.11 05:25
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Провокациями занялся ? Ну-ну.

Констатацией фактов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 18.04.11 05:27
Оценка:
Здравствуйте, ArtDenis, Вы писали:

AD>Идея хорошая. Надо взять на заметку.

AD>Из минусов вижу, что иногда протокол может быть настолько сложным, что его соблюдение невозможно будет контролировать в compile time. Но возможно, что это повод разбить протокол на несколько независимых уровней.
Павел привел ещё хороший пример, где этот подход просто так не применишь: когда шаги в протоколе представляют собой частично упорядоченное множество (здесь
Автор: Pavel Dvorkin
Дата: 16.04.11
).
Решение "в лоб" так, как я предлагаю, приведет к комбинаторному взрыву количества интерфейсов.
Re[18]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 18.04.11 05:30
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

0>>Твердо убежден, что если за разумную цену можно заставить компилятор что-то за меня контролировать, то это лучше сделать.

PD>Боюсь, что в серьезных задачах цена будет очень высокой.
Ответ на этот вопрос может дать только практическое исследование

Опять же, надо смотреть две ситуации:
1. Что можно получить на "обычном" языке, типа C#.
2. Что можно получить, если ввести в язык поддержку такого стиля.
Re[19]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 18.04.11 05:47
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Ответ на этот вопрос может дать только практическое исследование

Он всегда боится. А все по тому что за много лет что тут торчит не прочитал ни одной статьи по теме.

0>Опять же, надо смотреть две ситуации:

0>1. Что можно получить на "обычном" языке, типа C#.
В C# ничего хорошего.

0>2. Что можно получить, если ввести в язык поддержку такого стиля.

Нулевые издержки во время исполнения и около нулевые в исходном коде.
Скажем если это делать на основе этой статьи то чуть менее чем все выведет компилятор по аннотациям.
Все что нужно это расширить capability добавив в них состояние.
Те получится что-то в этом роде:
interface ISomething
{
    state Closed;
    state Opened;

    [Transient(Closed -> Opened)]
    void Open(...);

    [Transient(Opened)]
    void Read(...);
    [Transient(Opened)]
    void Write(...);

    [Transient(Opened -> Closed)]
    void Close(...);
}

Все остальное получится как в той статье.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 18.04.11 05:53
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Павел привел ещё хороший пример, где этот подход просто так не применишь: когда шаги в протоколе представляют собой частично упорядоченное множество (здесь
Автор: Pavel Dvorkin
Дата: 16.04.11
).

0>Решение "в лоб" так, как я предлагаю, приведет к комбинаторному взрыву количества интерфейсов.
За то это легко решается через капабилити скрещенные с type refinements.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 18.04.11 06:00
Оценка:
Здравствуйте, WolfHound, Вы писали:

0>>1. Что можно получить на "обычном" языке, типа C#.

WH>В C# ничего хорошего.
Точно? Не хотелось бы откладывать праздник жизни до появления в мэйнстриме нормальных языков
Re[28]: Интерфейс vs. протокол.
От: dotneter  
Дата: 18.04.11 06:10
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А теперь представь себе, что мне нужно по процентам двухкомпонентной смеси любого состава определить точку кипения смеси (эх, если бы это было возможно — нет такого способа расчета). И получишь ты в итоге float[-273..5000], то есть просто float.

И? Если у вас метода возвращает любое число, ну так замечательно, значит ограничений на величину никаких нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[19]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 18.04.11 07:28
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Pavel Dvorkin, Вы писали:


0>>>Твердо убежден, что если за разумную цену можно заставить компилятор что-то за меня контролировать, то это лучше сделать.

PD>>Боюсь, что в серьезных задачах цена будет очень высокой.
0>Ответ на этот вопрос может дать только практическое исследование

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

Поживем — увидим.
With best regards
Pavel Dvorkin
Re[29]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 18.04.11 07:30
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>А теперь представь себе, что мне нужно по процентам двухкомпонентной смеси любого состава определить точку кипения смеси (эх, если бы это было возможно — нет такого способа расчета). И получишь ты в итоге float[-273..5000], то есть просто float.

D>И? Если у вас метода возвращает любое число, ну так замечательно, значит ограничений на величину никаких нет.

Именно. И вся идея накрылась медным тазом. Все исходные вещества эти ограничения имеют каждое по себе, а все вместе — нет, а смеси — тоже. Поэтому если писать программу специально для воды, то что-то можно сделать, а для любого вещества — ничего.
With best regards
Pavel Dvorkin
Re[20]: Интерфейс vs. протокол.
От: 0x7be СССР  
Дата: 18.04.11 07:57
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну что же, подождем , когда оно произойдет. Я в этом отношении скептик. Доходов вижу мало, расходы несоразмерны, так что не думаю, что это всерьез где-то появится. А что касается всяких маргинальных языков — может быть, там оно и будет, только надо себе отдавать отчет, что ни один маргинальный язык никогда не попадал в мейнстрим.

Да, но есть другой процесс — мэйнстрим активно заимствует у "маргинальных" языков.
Re[30]: Интерфейс vs. протокол.
От: dotneter  
Дата: 18.04.11 08:21
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Именно. И вся идея накрылась медным тазом. Все исходные вещества эти ограничения имеют каждое по себе, а все вместе — нет, а смеси — тоже. Поэтому если писать программу специально для воды, то что-то можно сделать, а для любого вещества — ничего.

Да, для каждой задачи свои инструменты, где то работает одно где то другое. Возможно адепты зависимых типов смогут что нибудь придумать и для общего случая.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Talk is cheap. Show me the code.
Re[21]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 18.04.11 08:33
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Ну что же, подождем , когда оно произойдет. Я в этом отношении скептик. Доходов вижу мало, расходы несоразмерны, так что не думаю, что это всерьез где-то появится. А что касается всяких маргинальных языков — может быть, там оно и будет, только надо себе отдавать отчет, что ни один маргинальный язык никогда не попадал в мейнстрим.

0>Да, но есть другой процесс — мэйнстрим активно заимствует у "маргинальных" языков.

Ну что же, посмотрим.

With best regards
Pavel Dvorkin
Re[31]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 18.04.11 08:34
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Именно. И вся идея накрылась медным тазом. Все исходные вещества эти ограничения имеют каждое по себе, а все вместе — нет, а смеси — тоже. Поэтому если писать программу специально для воды, то что-то можно сделать, а для любого вещества — ничего.

D>Да, для каждой задачи свои инструменты, где то работает одно где то другое. Возможно адепты зависимых типов смогут что нибудь придумать и для общего случая.

Может быть. Повторю — я настроен скептически. Вернемся к этому разговору лет через 5
With best regards
Pavel Dvorkin
Re[30]: Интерфейс vs. протокол.
От: VoidEx  
Дата: 18.04.11 08:50
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


D>>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>>А теперь представь себе, что мне нужно по процентам двухкомпонентной смеси любого состава определить точку кипения смеси (эх, если бы это было возможно — нет такого способа расчета). И получишь ты в итоге float[-273..5000], то есть просто float.

D>>И? Если у вас метода возвращает любое число, ну так замечательно, значит ограничений на величину никаких нет.

PD>Именно. И вся идея накрылась медным тазом. Все исходные вещества эти ограничения имеют каждое по себе, а все вместе — нет, а смеси — тоже. Поэтому если писать программу специально для воды, то что-то можно сделать, а для любого вещества — ничего.


Ну, для любого вещества точку кипения ты и в рантайме не вычислишь, а если писать специально для воды, то и зависимые типы пригодятся. Т.е. идея пригодится в реализации вообще любой полезной программы.
Re[4]: Интерфейс vs. протокол.
От: vdimas Россия  
Дата: 18.04.11 08:51
Оценка:
Здравствуйте, jazzer, Вы писали:

J>он не покатит в рантайме, а во время компиляции все хорошо будет.

J>А 0x7be хочет, чтобы вторая строчка не компилировалась.
J>Поправь, если не так.

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

Разве на С++ возможно заставить компилятор ругаться на вторую строчку, если первая компилируется в этом выхолощенном примере?
A a1 = f(b);
A a2 = f(b);
Re[5]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 18.04.11 08:57
Оценка:
Здравствуйте, vdimas, Вы писали:

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


J>>он не покатит в рантайме, а во время компиляции все хорошо будет.

J>>А 0x7be хочет, чтобы вторая строчка не компилировалась.
J>>Поправь, если не так.

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


Нет, у меня будет ошибка компиляции.
При том что и у тебя, и у меня возвращаемое значение передается дальше правильно, у тебя — ошибка времени исполнения, а у меня — времени компиляции.

V>Разве на С++ возможно заставить компилятор ругаться на вторую строчку, если первая компилируется в этом выхолощенном примере?

V>
V>A a1 = f(b);
V>A a2 = f(b);
V>

В этом — нет, а в таком — можно:
A a0;
auto a1 = f(b, a0);
auto a2 = f(b, a1);


Условие задачи было — предоставить статический контроль. Пусть криво и косо, но чтоб был. Где он у тебя? Нету, только рантайм. А рантайм у нас и сейчас есть в виде исключений и прочих проверок времени выполнения.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[20]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 18.04.11 09:05
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну что же, подождем , когда оно произойдет.

Уже. Но так как ты не в состоянии прочитать даже парочку статей из рецензируемых журналов то ты об этом не узнаешь.

PD>Я в этом отношении скептик. Доходов вижу мало, расходы несоразмерны, так что не думаю, что это всерьез где-то появится.

Ага, конечно.
Вот очередной пример: http://lamp.epfl.ch/~phaller/uniquerefs/capabilities_for_uniqueness_TR.pdf
Доходы: Доказанное отсутствие гонок.
Расходы: В рантайме строго ноль. В исходниках

We have implemented OCT as an extension of the EPFL Scala compiler. In Section 8.1 we show that virtually all methods of common collection classes in Scala's standard library can be annotated with uniqueness information in a simple way without any changes to their implementation.


PD>А что касается всяких маргинальных языков — может быть, там оно и будет, только надо себе отдавать отчет, что ни один маргинальный язык никогда не попадал в мейнстрим.

Ведешь себя в точности по моему описанию. Хоть бы постеснялся.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Интерфейс vs. протокол.
От: vdimas Россия  
Дата: 18.04.11 10:37
Оценка:
Здравствуйте, jazzer, Вы писали:

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


J>Нет, у меня будет ошибка компиляции.


Эх, невнимательность...

Покажи тут ошибку компиляции:
auto s4 = f.go( s3, Close()            );
auto s5 = f.go( s3, Close()            );


J>При том что и у тебя, и у меня возвращаемое значение передается дальше правильно, у тебя — ошибка времени исполнения, а у меня — времени компиляции.


Неверно.

V>>Разве на С++ возможно заставить компилятор ругаться на вторую строчку, если первая компилируется в этом выхолощенном примере?

V>>
V>>A a1 = f(b);
V>>A a2 = f(b);
V>>

J>В этом — нет, а в таком — можно:
J>
J>A a0;
J>auto a1 = f(b, a0);
J>auto a2 = f(b, a1);
J>


А такой не решает исходную задачу, ибо не гарантирует протокол.

J>Условие задачи было — предоставить статический контроль. Пусть криво и косо, но чтоб был. Где он у тебя? Нету, только рантайм.


Выше показал в чем суть. Мой пример a1=f(b) — это выхолощенный случай как твоего, та и моего варианта. Чуть присмотрись. В нем и есть слабость твоего и моего решения. Она, эта "слабость", идентична.


J>А рантайм у нас и сейчас есть в виде исключений и прочих проверок времени выполнения.


Э нет, в моем примере, как и в твоем, если удалось отладить "основную ветку", то компилятор ограничивает набор возможных "неосновных". Т.е. отладка здесь ровно идет того же плана, что ловля поданного ошибочного NULL. А от него С++ тоже не спасает, со всей своей типизированностью. И не только С++ тут бессилен.
Re[19]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 18.04.11 11:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ром, если у НКА объединить состояния, как это сделал ты, то как раз получится ДКА.

На самом деле тут все еще веселее.
Рома записал не НКА, а ДКА.
У него фактически написано, что при возникновении сигнала A перейти в состояние X.
Полный детерминизм.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[31]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 18.04.11 11:59
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Ну, для любого вещества точку кипения ты и в рантайме не вычислишь,


Увы, да. Но тут причины химические, а не математико-влгоритмические.

>а если писать специально для воды


То 100 С.

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


А вот с этим не согласен. Аргументацию повторять не буду, уже не раз писал.
With best regards
Pavel Dvorkin
Re[21]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 18.04.11 12:00
Оценка:
Здравствуйте, WolfHound, Вы писали:

PD>>А что касается всяких маргинальных языков — может быть, там оно и будет, только надо себе отдавать отчет, что ни один маргинальный язык никогда не попадал в мейнстрим.

WH>Ведешь себя в точности по моему описанию. Хоть бы постеснялся.

Надоел.
With best regards
Pavel Dvorkin
Re[7]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 18.04.11 12:05
Оценка:
Здравствуйте, vdimas, Вы писали:

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


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


J>>Нет, у меня будет ошибка компиляции.


V>Эх, невнимательность...


V>Покажи тут ошибку компиляции:

V>
V>auto s4 = f.go( s3, Close()            );
V>auto s5 = f.go( s3, Close()            );
V>


J>>При том что и у тебя, и у меня возвращаемое значение передается дальше правильно, у тебя — ошибка времени исполнения, а у меня — времени компиляции.


Смотри, я тут не просто так выделенные слова написал. Если всё передается правильно и у тебя, и у меня, то у меня будет ошибка компиляции, а у тебя — нет. По крайней мере, я ее тут не вижу, покажи, если она тут есть.

А то, что ты показываешь с s3 — это неправильная передача значения, в таком случае схема работать не будет. Но и на нее есть управа — можно передавать сразу всю цепочку действий, которые мы хотим совершить, и она будет проверена опять же на этапе компиляции (go_chain в моем примере). Там достаточно гарантировать, что самое начальное состояние правильное, а дальше все промежуточные в цепочки будут правильными автоматически.

V>Неверно.


V>>>Разве на С++ возможно заставить компилятор ругаться на вторую строчку, если первая компилируется в этом выхолощенном примере?

V>>>
V>>>A a1 = f(b);
V>>>A a2 = f(b);
V>>>

J>>В этом — нет, а в таком — можно:
J>>
J>>A a0;
J>>auto a1 = f(b, a0);
J>>auto a2 = f(b, a1);
J>>


V>А такой не решает исходную задачу, ибо не гарантирует протокол.

У меня — гарантирует, если передается действительно a0 и а1, а не что-то другое. А у тебя, даже если передается везде правильный file, все равно контроль только во время выполнения.

J>>Условие задачи было — предоставить статический контроль. Пусть криво и косо, но чтоб был. Где он у тебя? Нету, только рантайм.


V>Выше показал в чем суть. Мой пример a1=f(b) — это выхолощенный случай как твоего, та и моего варианта. Чуть присмотрись. В нем и есть слабость твоего и моего решения. Она, эта "слабость", идентична.


Да у тебя вообще статики нет, либо я слепой с утра.

J>>А рантайм у нас и сейчас есть в виде исключений и прочих проверок времени выполнения.


V>Э нет, в моем примере, как и в твоем, если удалось отладить "основную ветку", то компилятор ограничивает набор возможных "неосновных". Т.е. отладка здесь ровно идет того же плана, что ловля поданного ошибочного NULL. А от него С++ тоже не спасает, со всей своей типизированностью. И не только С++ тут бессилен.

Покажи, где компилятор ругнется в твоем примере. Я не вижу, сорри.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: Интерфейс vs. протокол.
От: vdimas Россия  
Дата: 18.04.11 12:35
Оценка:
Здравствуйте, jazzer, Вы писали:


V>>Покажи тут ошибку компиляции:

V>>
V>>auto s4 = f.go( s3, Close()            );
V>>auto s5 = f.go( s3, Close()            );
V>>


J>>>При том что и у тебя, и у меня возвращаемое значение передается дальше правильно, у тебя — ошибка времени исполнения, а у меня — времени компиляции.


J>Смотри, я тут не просто так выделенные слова написал. Если всё передается правильно и у тебя, и у меня, то у меня будет ошибка компиляции, а у тебя — нет. По крайней мере, я ее тут не вижу, покажи, если она тут есть.


Ты так и не показал ошибку компиляции в приведенном мною фрагменте, а в нем суть. Происходит следующее — мы переиспользуем некую переменную s3, несмотря на то, что она уже содержит ссылку на невалидное состояние. Именно в отсутствии ср-в контроля за моментом, когда переменная становится невалидной, мы можем лишь приблизительно воспроизводить решение, но не точно.

J>А то, что ты показываешь с s3 — это неправильная передача значения, в таком случае схема работать не будет.


Она не будет работать в рантайм. Но компилятор же об этом не скажет.

J>Но и на нее есть управа — можно передавать сразу всю цепочку действий, которые мы хотим совершить, и она будет проверена опять же на этапе компиляции (go_chain в моем примере). Там достаточно гарантировать, что самое начальное состояние правильное, а дальше все промежуточные в цепочки будут правильными автоматически.


Именно, нужна некая монада, которая результат предыдущей ф-ии автоматически подаст как аргумент следующей. Тогда (при условии отсутствия ошибок внутри самих ф-ий) еще хоть как-то можно замутить некую "безопасность". Хаскель в руки, как говорится.


V>>А такой не решает исходную задачу, ибо не гарантирует протокол.

J>У меня — гарантирует, если передается действительно a0 и а1, а не что-то другое. А у тебя, даже если передается везде правильный file, все равно контроль только во время выполнения.

Да нет, просто ты забил болт на конструкторы копирования и деструкторы. Т.е. при выходе из диапазона, если явно не закрыть файл, то он повиснет в воздухе. ОК, замени в моем примере на shared_ptr или другой случай подсчета ссылок и будет тебе щастье. ИМХО, передача владения всяко дешевле выходит, хотя теряем немного в автоматизме. И для данного примера выбранный способ детерминированного разрушения — не суть.

V>>Выше показал в чем суть. Мой пример a1=f(b) — это выхолощенный случай как твоего, та и моего варианта. Чуть присмотрись. В нем и есть слабость твоего и моего решения. Она, эта "слабость", идентична.



J>Да у тебя вообще статики нет, либо я слепой с утра.


Статика одинакова в обоих примерах и заключается в том, что каждое состояние — это отдельный тип, для которого определены некие операции. Просто я опустил состояние Initial и Closed, которые избыточны для этого примера, и оставил только состояние file. Вернув твою избыточность получим:
InitialPtr initial;
OpenedPtr file = openFile(initial, "some-path");
file = read(file, &buffer, count);
file = read(file, &buffer2, count2);
ClosedPtr closed = close(file);


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

J>Покажи, где компилятор ругнется в твоем примере. Я не вижу, сорри.


Компилятор ругнется, если в read() мы подадим аргумент не того типа. Например: read(initial, ...). Собсно, как и у тебя. Если бы ты не свел свой пример к одной сигнатуре, макросам и явно выделенному автомату, я бы не встревал. Это все лишнее для демонстрации происходящего.
Re[22]: Интерфейс vs. протокол.
От: VladD2 Российская Империя www.nemerle.org
Дата: 18.04.11 14:27
Оценка:
Здравствуйте, adontz, Вы писали:

A>http://www.rsdn.ru/article/singularity/singularity.xml
Автор(ы): Galen Hunt, James Larus, Martin Abadi, Mark Aiken, Paul Barham, Manuel Fahndrich, Chris Hawblitzel, Orion Hodson, Steven Levi, Nick Murphy, Bjarne Steensgaard, David Tarditi, Ted Wobber, Brian Zill
Дата: 02.03.2006
Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?


A>

Singularity выдала 91 операцию в секунду при взвешенной средней пропускной способности в 362 Kбит/с. Web-сервер IIS, выполняемый под управлением Windows 2003 на идентичной аппаратуре, выдает 761 операцию в секунду при взвешенной средней пропускной способности в 336 Kбит/с.


A>

Сетевой стек Singularity, наоборот, не является узким местом, и может поддерживать пропускную способность в 48Mбит/сек.


A>Статья старая, но даже по тогдашним меркам производительность просто нелепая. В обсуждении (не очень большом) это обсосано.


И что нелепого ты тут усмотрел? Ну, одна какая-то фича не отлажена. Пропускная способность в килобитах одинаковая, кстати.

Если поглядеть на табличку сверху, то как раз видно, что как ОС Сингулярити даже по шустрее Винды.
http://www.rsdn.ru/article/singularity/singularity.xml#EIIAE
Автор(ы): Galen Hunt, James Larus, Martin Abadi, Mark Aiken, Paul Barham, Manuel Fahndrich, Chris Hawblitzel, Orion Hodson, Steven Levi, Nick Murphy, Bjarne Steensgaard, David Tarditi, Ted Wobber, Brian Zill
Дата: 02.03.2006
Singularity – исследовательский проект Microsoft Research, который начался с вопроса: на что была бы похожа программная платформа, если спроектировать ее на пустом месте, и во главу угла поставить не производительность, а надежность?

Singularity – это новая система, и ее производительность пока не отлажена до конца. Основные операции с потоками в Singularity, такие, как передача процессорного времени (yielding processor) или синхронизация двух потоков, сравнимы или несколько быстрее, чем на других системах. Однако, благодаря SIP-архитектуре Singularity, межпроцессные операции выполняются значительно быстрее, чем в других системах. Вызовы ядра из процесса в Singularity в 5-10 раз быстрее, поскольку вызов не пересекает границ аппаратной защиты. Простое RPC-подобное взаимодействие двух процессов в 4-9 раз быстрее. А создание процесса в 2-18 раз быстрее, чем в других системах. Это превосходство должно еще больше вырасти, когда мы улучшим реализацию потоков в Singularity.


И это на совсем новой, не отлаженной (в то время) системе. Думаю, что сейчас уже она сильно стабильнее и шустрее.

Так что ты Ром опять гонишь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 18.04.11 17:20
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ты так и не показал ошибку компиляции в приведенном мною фрагменте, а в нем суть.

Естественно, не показал, потому что я как раз хотел показать, что ее нет, а 0x7be просит, чтоб она была!

V>Происходит следующее — мы переиспользуем некую переменную s3, несмотря на то, что она уже содержит ссылку на невалидное состояние. Именно в отсутствии ср-в контроля за моментом, когда переменная становится невалидной, мы можем лишь приблизительно воспроизводить решение, но не точно.


Да я отлично понимаю, что происходит, но это не решение той задачи, которую предложил 0x7be.

J>>А то, что ты показываешь с s3 — это неправильная передача значения, в таком случае схема работать не будет.

V>Она не будет работать в рантайм. Но компилятор же об этом не скажет.
Да, не скажет. Но даже когда правильная передача, у тебя рантайм, а у меня статика.

J>>Но и на нее есть управа — можно передавать сразу всю цепочку действий, которые мы хотим совершить, и она будет проверена опять же на этапе компиляции (go_chain в моем примере). Там достаточно гарантировать, что самое начальное состояние правильное, а дальше все промежуточные в цепочки будут правильными автоматически.


V>Именно, нужна некая монада, которая результат предыдущей ф-ии автоматически подаст как аргумент следующей. Тогда (при условии отсутствия ошибок внутри самих ф-ий) еще хоть как-то можно замутить некую "безопасность". Хаскель в руки, как говорится.


Ну вот у меня С++ ничего так, цепочки вызовов проверяет
С Хаскелем, конечно, было бы проще, а еще проще — с какой-нть Агдой2.

V>Да нет, просто ты забил болт на конструкторы копирования и деструкторы. Т.е. при выходе из диапазона, если явно не закрыть файл, то он повиснет в воздухе. ОК, замени в моем примере на shared_ptr или другой случай подсчета ссылок и будет тебе щастье. ИМХО, передача владения всяко дешевле выходит, хотя теряем немного в автоматизме. И для данного примера выбранный способ детерминированного разрушения — не суть.


Ага, тем более что у меня автоматические объекты везде и нулевой оверхед в рантайме. Куда уж дешевле

Причем тут конструкторы и деструкторы? 0x7be ясно описал задачу — методы могут вызываться в определенном порядке, и точка. Это — описание конечного автомата с его разрешенными переходами между состояниями. И все это происходит между конструкторами и деструкторами, они за скобками.

V>Статика одинакова в обоих примерах и заключается в том, что каждое состояние — это отдельный тип, для которого определены некие операции. Просто я опустил состояние Initial и Closed, которые избыточны для этого примера, и оставил только состояние file. Вернув твою избыточность получим:

V>
V>InitialPtr initial;
V>OpenedPtr file = openFile(initial, "some-path");
V>file = read(file, &buffer, count);
V>file = read(file, &buffer2, count2);
V>ClosedPtr closed = close(file);
V>


V>Заметь, мой пример лучше передает смысл происходящего, т.к. не ограничивает сигнатуру операций.

Это где это у меня ограничены сигнатуры? У меня сигнатура — это все содержимое сигнала, там сколько угодно параметров может быть. Например, Close вообще без параметров. А так — то же, что у меня, получается, так что не очень понятно, с чем ты споришь.

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

Да, на этом все построено и у меня, и у тебя. Причем тут уникальные ссылки, о которых ты так долго говорил — не понимаю.

J>>Покажи, где компилятор ругнется в твоем примере. Я не вижу, сорри.


V>Компилятор ругнется, если в read() мы подадим аргумент не того типа. Например: read(initial, ...). Собсно, как и у тебя. Если бы ты не свел свой пример к одной сигнатуре, макросам и явно выделенному автомату, я бы не встревал. Это все лишнее для демонстрации происходящего.


Теперь я наконец понял, о чем ты. Ты так налегал на уникальность ссылки, что я решил, что у тебя через нее все и делается (естественно, только в рантайме). А теперь, когда ты показал все целиком, я вижу, что у тебя ровно то же самое, что и у меня, получается. С той лишь разницей, что я могу объявить цепочку действий и через go_chain проверить ее сразу же компилятором, а ты нет (так как каждый метод у меня — это отдельный тип, а у тебя это просто функции, сигнатуры которых могут совпадать и давать одинаковый тип). Цепочки вообще гораздо безопаснее, так как гарантируют не только правильность порядка вызовов, но и то, что цепочка применяется к одному и тому же объекту, исключая целый класс копи-пейстных ошибок типа
V>file1 = read(file1, &buffer, count);
V>file1 = read(file2, &buffer2, count2); // ой, file2 скопировали из другого места и не заметили
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[10]: Интерфейс vs. протокол.
От: vdimas Россия  
Дата: 18.04.11 20:40
Оценка:
Здравствуйте, jazzer, Вы писали:

V>>Ты так и не показал ошибку компиляции в приведенном мною фрагменте, а в нем суть.

J>Естественно, не показал, потому что я как раз хотел показать, что ее нет, а 0x7be просит, чтоб она была!

Именно, на пару постов вверх и в выолощенном примере я показал, где засада. Эта засада одинакова и не контроллируется компилятором.

V>>Происходит следующее — мы переиспользуем некую переменную s3, несмотря на то, что она уже содержит ссылку на невалидное состояние. Именно в отсутствии ср-в контроля за моментом, когда переменная становится невалидной, мы можем лишь приблизительно воспроизводить решение, но не точно.


J>Да я отлично понимаю, что происходит, но это не решение той задачи, которую предложил 0x7be.


Ес-но, эту задачу в рамках C++ не решить. Мне просто непонятно твое упорство в том плане, что мое решение по-сути отличается от твоего. Оно не может отличаться, мы используем одинаковый механизм.


J>>>А то, что ты показываешь с s3 — это неправильная передача значения, в таком случае схема работать не будет.

V>>Она не будет работать в рантайм. Но компилятор же об этом не скажет.
J>Да, не скажет. Но даже когда правильная передача, у тебя рантайм, а у меня статика.

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


J>Ну вот у меня С++ ничего так, цепочки вызовов проверяет

J>С Хаскелем, конечно, было бы проще, а еще проще — с какой-нть Агдой2.

Просто нужен синтаксис и поддержка компилятора для такого фокуса. В Хаскеле это есть.


J>Ага, тем более что у меня автоматические объекты везде и нулевой оверхед в рантайме. Куда уж дешевле


Ты хотел сказать стековые? Для случая файла на порядок дешевле создать в куче некий "shared object", чем делать DuplicateHandle/CloseHandle в каждом конструкторе копирования и деструкторе состояния Opened.

J>Причем тут конструкторы и деструкторы? 0x7be ясно описал задачу — методы могут вызываться в определенном порядке, и точка. Это — описание конечного автомата с его разрешенными переходами между состояниями. И все это происходит между конструкторами и деструкторами, они за скобками.


Дык, он же не дал язык. Если берем С++, то нужны ср-ва для контроля ресурсов. Если бы за ресурсами в С++ следить не надо было, 90% кода можно было написать иначе.


J>Это где это у меня ограничены сигнатуры? У меня сигнатура — это все содержимое сигнала, там сколько угодно параметров может быть. Например, Close вообще без параметров. А так — то же, что у меня, получается, так что не очень понятно, с чем ты споришь.


Я выкинул лишнее, чтобы показать суть. Содержимое сигнала — это не сигнатура, это притянутые за уши ограничения выбранной "автоматной" схемы. Любая сигнатура — это произвольная ф-ия, имеющая как минимум одним аргументом наше типизированное состояние. А проивольный код ты туда в макрос не воткнешь. Остроумно было использовать operator<<, потому как оно корректно будет проглочено компилятором. Но что-то посложнее — увы. Я же говорю — это всё лишее, достаточно каждое состояние представить в виде уникального типа, остальное получается само.

J>Да, на этом все построено и у меня, и у тебя. Причем тут уникальные ссылки, о которых ты так долго говорил — не понимаю.


Для того, чтобы твоё s3 нельзя было переиспользовать после Close(). Да, тоже притянутость за уши, согласен, но тут иначе никак. У тебя сей момент вообще не контролируется, т.е. в случае ошибки при вызове методов для закрытого файла диагностировать это в общем случае будет труднее. А у меня задуман как бы специальный smart-pointer, который выплюнет ошибку вроде "нарушение протокола".

J>Теперь я наконец понял, о чем ты. Ты так налегал на уникальность ссылки, что я решил, что у тебя через нее все и делается (естественно, только в рантайме).


Уникальность, как уже сказал — это единственный способ гарантировать протокол. Ввиду того, что уникальность в С++ не подерживается, был предожен этот костыль.

J>А теперь, когда ты показал все целиком, я вижу, что у тебя ровно то же самое, что и у меня, получается. С той лишь разницей, что я могу объявить цепочку действий и через go_chain проверить ее сразу же компилятором, а ты нет (так как каждый метод у меня — это отдельный тип, а у тебя это просто функции, сигнатуры которых могут совпадать и давать одинаковый тип).


У тебя не метод, а сообщение суть отдельный тип. А это ограничение структуры. Фишка в том, что если "сигнатуры совпадают", как ты говоришь, то контракт и не нарушится, т.е. не о чем беспокоится. А приписать внешний go_chain — дело техники и тысячи вариантов, с той разницей, что ты замыкание аргументов явно прописал в виде сообщений, но можно сделать автоматически, даже в текущем стандарте через boost::bind.


J>Цепочки вообще гораздо безопаснее, так как гарантируют не только правильность порядка вызовов, но и то, что цепочка применяется к одному и тому же объекту, исключая целый класс копи-пейстных ошибок типа


Я с этим и не спорю. Более того, повторю, статически типизированный язык на мой взгляд должен требовать, чтобы результат вызова ф-ии,отличный от void, куда-то девался. Тогда у нас вся программа будет представлять из себя эти "цепочки", пусть даже через промежуточные переменные. А если еще добавить константность на эти значения, будет совсем красиво и надежно.
Re[32]: Интерфейс vs. протокол.
От: VoidEx  
Дата: 19.04.11 06:18
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


VE>>Ну, для любого вещества точку кипения ты и в рантайме не вычислишь,


PD>Увы, да. Но тут причины химические, а не математико-влгоритмические.


Именно. Причины бесполезности зависимых типов в твоём надуманном примере химические, а не математически-алгоритмические. О чём тебе и говорят.
Re[11]: Интерфейс vs. протокол.
От: jazzer Россия Skype: enerjazzer
Дата: 19.04.11 06:19
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Ес-но, эту задачу в рамках C++ не решить. Мне просто непонятно твое упорство в том плане, что мое решение по-сути отличается от твоего. Оно не может отличаться, мы используем одинаковый механизм.


Где упорство, я же в конце написал, что идеи решения идентичны, разница только в деталях

V>Повторю, мое решение идентично твоему, только оно не завернуто в "автоматную" оболочку. Эта оболочка лишняя, не добавляет ни йоты полезного функционала. Я не говорю, что сам автоматный подход не нужен (сам охотно пользую), речь о конкретной задаче.


Она не завернута явно, но твои InitialPtr, OpenPtr и ClosedPtr — это же состояния КА, так что хоть горшком назови

V>Просто нужен синтаксис и поддержка компилятора для такого фокуса. В Хаскеле это есть.

Да.

J>>Ага, тем более что у меня автоматические объекты везде и нулевой оверхед в рантайме. Куда уж дешевле

V>Ты хотел сказать стековые?
Не обязательно, они могут быть членами классов, например. Automatic storage duration, короче.

V>Для случая файла на порядок дешевле создать в куче некий "shared object", чем делать DuplicateHandle/CloseHandle в каждом конструкторе копирования и деструкторе состояния Opened.

А у меня этого и нету, это у тебя file передается, по-разному обернутый, а у меня передается его состояние, которое с тем, кто и как владеет файлом, никак не связаны. А у тебя смешано владение и состояние.

J>>Причем тут конструкторы и деструкторы? 0x7be ясно описал задачу — методы могут вызываться в определенном порядке, и точка. Это — описание конечного автомата с его разрешенными переходами между состояниями. И все это происходит между конструкторами и деструкторами, они за скобками.


V>Дык, он же не дал язык. Если берем С++, то нужны ср-ва для контроля ресурсов. Если бы за ресурсами в С++ следить не надо было, 90% кода можно было написать иначе.

Ну я-то на С++ пишу на работе, так что мне интересен именно он
А контроль ресурсов мне тут не нужен, не понимаю, почему ты так на него напираешь.

J>>Это где это у меня ограничены сигнатуры? У меня сигнатура — это все содержимое сигнала, там сколько угодно параметров может быть. Например, Close вообще без параметров. А так — то же, что у меня, получается, так что не очень понятно, с чем ты споришь.


V>Я выкинул лишнее, чтобы показать суть. Содержимое сигнала — это не сигнатура, это притянутые за уши ограничения выбранной "автоматной" схемы. Любая сигнатура — это произвольная ф-ия, имеющая как минимум одним аргументом наше типизированное состояние.

Чем тебя не устраивает вызов f.go( s, Read{data_to_read} )? Что ты там хотел, буфер передавать с размером? Тогда это будет выглядеть так: f.go( s, Read{&buffer, size} ).

V>А проивольный код ты туда в макрос не воткнешь. Остроумно было использовать operator<<, потому как оно корректно будет проглочено компилятором. Но что-то посложнее — увы.

Еще как воткну, ты думаешь, я только на operator<< тестировал? Ты просто не знаешь силы variadic macros. Вообще говоря, единственное, что может сломать макрос — это запятая, которая неизбежно увеличивает количество параметров. Отсюда весь гемор. С появлением variadic macros этой проблемы больше нет.

V>Я же говорю — это всё лишее, достаточно каждое состояние представить в виде уникального типа, остальное получается само.

У меня оно и представлено.

J>>Да, на этом все построено и у меня, и у тебя. Причем тут уникальные ссылки, о которых ты так долго говорил — не понимаю.


V>Для того, чтобы твоё s3 нельзя было переиспользовать после Close(). Да, тоже притянутость за уши, согласен, но тут иначе никак. У тебя сей момент вообще не контролируется, т.е. в случае ошибки при вызове методов для закрытого файла диагностировать это в общем случае будет труднее. А у меня задуман как бы специальный smart-pointer, который выплюнет ошибку вроде "нарушение протокола".

Да ладно. Сам файл в состоянии в рантайме проконтролировать, что его уже закрыли, и бросить исключение, точно так же, как это делается сейчас. Никакой разницы с твоим обнулившимся указателем, который точно так же проверяется в рантайме.

J>>Теперь я наконец понял, о чем ты. Ты так налегал на уникальность ссылки, что я решил, что у тебя через нее все и делается (естественно, только в рантайме).


V>Уникальность, как уже сказал — это единственный способ гарантировать протокол. Ввиду того, что уникальность в С++ не подерживается, был предожен этот костыль.

Битва костылей

J>>А теперь, когда ты показал все целиком, я вижу, что у тебя ровно то же самое, что и у меня, получается. С той лишь разницей, что я могу объявить цепочку действий и через go_chain проверить ее сразу же компилятором, а ты нет (так как каждый метод у меня — это отдельный тип, а у тебя это просто функции, сигнатуры которых могут совпадать и давать одинаковый тип).


V>У тебя не метод, а сообщение суть отдельный тип. А это ограничение структуры. Фишка в том, что если "сигнатуры совпадают", как ты говоришь, то контракт и не нарушится, т.е. не о чем беспокоится.

см. выше. не вижу разницы.
V>А приписать внешний go_chain — дело техники и тысячи вариантов, с той разницей, что ты замыкание аргументов явно прописал в виде сообщений, но можно сделать автоматически, даже в текущем стандарте через boost::bind.
Ну вот припиши внешний go_chain в твоей схеме, чтоб была ошибка компиляции, и сравним.
В моей это делается тремя строчками, см. мое исходное сообщение. Как это сделать просто в твоей — я не вижу.

J>>Цепочки вообще гораздо безопаснее, так как гарантируют не только правильность порядка вызовов, но и то, что цепочка применяется к одному и тому же объекту, исключая целый класс копи-пейстных ошибок типа


V>Я с этим и не спорю. Более того, повторю, статически типизированный язык на мой взгляд должен требовать, чтобы результат вызова ф-ии,отличный от void, куда-то девался. Тогда у нас вся программа будет представлять из себя эти "цепочки", пусть даже через промежуточные переменные. А если еще добавить константность на эти значения, будет совсем красиво и надежно.

Ну, это можно сделать каким-нть внешним статическим анализатором или плагином к компилятору, благо GCC позволяет плагины подключать к нему, начиная с версии 4.5. Только это не поможет. Ну денется результат куда-то, как ты застрахуешь программера от того, что он потом не перепутает s1 и s2, которые ты заставил его создать?

ЗЫ Прикинь, придется же писать
std::ostream& i_hate_this_return_policy = std::cout << "Oh no!";

jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[33]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 19.04.11 07:33
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>Здравствуйте, Pavel Dvorkin, Вы писали:


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


VE>>>Ну, для любого вещества точку кипения ты и в рантайме не вычислишь,


PD>>Увы, да. Но тут причины химические, а не математико-влгоритмические.


VE>Именно. Причины бесполезности зависимых типов в твоём надуманном примере химические, а не математически-алгоритмические. О чём тебе и говорят.


Нет. Говоря о химических причинах, я просто имел в виду, что в химии нет методов, позволяющих рассчитывать эти значения с хорошей точностью. Это химический факт, не имеющий к теме дискуссии отношения. Предположим, что такой метод создан, что тогда ? Бесполезность типов вдруг исчезнет и появится полезность ? Из-за того, что кто-то разработал метод расчета, не имеющий отношения к информатике ? Сами-то величины вполне определены, и очень даже неплохо.
Кстати, вполне могу предложить пример, когда расчет вполне возможен. Например, расчет энтальпии образования с хорошей точностью для ряда органических веществ вполне возможен. Но какое это отношение к программированию имеет ?
With best regards
Pavel Dvorkin
Re[34]: Интерфейс vs. протокол.
От: VoidEx  
Дата: 19.04.11 08:59
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


VE>>Здравствуйте, Pavel Dvorkin, Вы писали:


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


VE>>>>Ну, для любого вещества точку кипения ты и в рантайме не вычислишь,


PD>>>Увы, да. Но тут причины химические, а не математико-влгоритмические.


VE>>Именно. Причины бесполезности зависимых типов в твоём надуманном примере химические, а не математически-алгоритмические. О чём тебе и говорят.


PD>Нет. Говоря о химических причинах, я просто имел в виду, что в химии нет методов, позволяющих рассчитывать эти значения с хорошей точностью. Это химический факт, не имеющий к теме дискуссии отношения. Предположим, что такой метод создан, что тогда ?

Тогда мы сможем вычислить в процессе компиляции и возвращать в функции float[computelow..computehigh]
Re[35]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 19.04.11 09:13
Оценка:
Здравствуйте, VoidEx, Вы писали:

PD>>Нет. Говоря о химических причинах, я просто имел в виду, что в химии нет методов, позволяющих рассчитывать эти значения с хорошей точностью. Это химический факт, не имеющий к теме дискуссии отношения. Предположим, что такой метод создан, что тогда ?

VE>Тогда мы сможем вычислить в процессе компиляции и возвращать в функции float[computelow..computehigh]

А если эти low и high были оценены неверно ? Их оценить для произвольного вещества, допустим, нельзя, так как метод расчета зависит от каких-то параметров, которые берутся из эксперимента, а он для этих веществ еще не проводился (ситуация вполне реальная : метод расчета есть, данных для него для некоего вещества пока нет)

Я вообще не понимаю, что должно быть в этом случае. Ты же предлагаешь статический анализ, то есть во время компиляции. А мне исходники, естественно, не дашь, если это коммерческая программа ? И вот я ей даю на вход вещество, для которого должно получится <low или > high. И что ?
With best regards
Pavel Dvorkin
Re[36]: Интерфейс vs. протокол.
От: VoidEx  
Дата: 19.04.11 09:23
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


PD>>>Нет. Говоря о химических причинах, я просто имел в виду, что в химии нет методов, позволяющих рассчитывать эти значения с хорошей точностью. Это химический факт, не имеющий к теме дискуссии отношения. Предположим, что такой метод создан, что тогда ?

VE>>Тогда мы сможем вычислить в процессе компиляции и возвращать в функции float[computelow..computehigh]

PD>А если эти low и high были оценены неверно ? Их оценить для произвольного вещества, допустим, нельзя, так как метод расчета зависит от каких-то параметров, которые берутся из эксперимента, а он для этих веществ еще не проводился (ситуация вполне реальная : метод расчета есть, данных для него для некоего вещества пока нет)

low и high и так на этапе компиляции неизвестны, если ты об этом.

PD>Я вообще не понимаю, что должно быть в этом случае. Ты же предлагаешь статический анализ, то есть во время компиляции. А мне исходники, естественно, не дашь, если это коммерческая программа ? И вот я ей даю на вход вещество, для которого должно получится <low или > high. И что ?

Не понял вопроса.
Re[37]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 19.04.11 09:34
Оценка:
Здравствуйте, VoidEx, Вы писали:

VE>low и high и так на этапе компиляции неизвестны, если ты об этом.


Тогда я не понимаю, как функция может вернуть ограниченный float[low..high]

PD>>Я вообще не понимаю, что должно быть в этом случае. Ты же предлагаешь статический анализ, то есть во время компиляции. А мне исходники, естественно, не дашь, если это коммерческая программа ? И вот я ей даю на вход вещество, для которого должно получится <low или > high. И что ?

VE>Не понял вопроса.

Задача.

Есть метод расчета чего-то для неопределенного числа различных веществ .
Метод зависит от параметров.Параметры вводятся из файла. Для каждого вещества они свои.
Опиши, как будешь программу делать со статическим анализом.
With best regards
Pavel Dvorkin
Re[38]: Интерфейс vs. протокол.
От: WolfHound  
Дата: 19.04.11 09:56
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Тогда я не понимаю, как функция может вернуть ограниченный float[low..high]

Пятисотый раз повторяю: Читай про зависимые типы.

PD>Есть метод расчета чего-то для неопределенного числа различных веществ .

PD>Метод зависит от параметров.Параметры вводятся из файла. Для каждого вещества они свои.
Да плевать откуда они беруться.
Читай про зависимые типы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 19.04.11 09:59
Оценка:
Здравствуйте, VoidEx, Вы писали:

PD>>Тогда я не понимаю, как функция может вернуть ограниченный float[low..high]


VE>Тут 22 страницы со ссылками на зависимые типы.


Если можешь объяснить (на пальцах), как это должно компилироваться и работать (пример, который я привел) — объясни. Если нет — закончим дискуссию.
With best regards
Pavel Dvorkin
Re[40]: Интерфейс vs. протокол.
От: hardcase Пират http://nemerle.org
Дата: 19.04.11 10:03
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Если можешь объяснить (на пальцах), как это должно компилироваться и работать (пример, который я привел) — объясни. Если нет — закончим дискуссию.


А как вообще работает вывод типов в языках?
Или он тоже не работает в "условиях в реальных проектов"?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[12]: Интерфейс vs. протокол.
От: vdimas Россия  
Дата: 19.04.11 11:16
Оценка:
Здравствуйте, jazzer, Вы писали:

V>>Я с этим и не спорю. Более того, повторю, статически типизированный язык на мой взгляд должен требовать, чтобы результат вызова ф-ии,отличный от void, куда-то девался. Тогда у нас вся программа будет представлять из себя эти "цепочки", пусть даже через промежуточные переменные. А если еще добавить константность на эти значения, будет совсем красиво и надежно.

J>Ну, это можно сделать каким-нть внешним статическим анализатором или плагином к компилятору, благо GCC позволяет плагины подключать к нему, начиная с версии 4.5.

J>ЗЫ Прикинь, придется же писать

J>
J>std::ostream& i_hate_this_return_policy = std::cout << "Oh no!";
J>

J>

Вот еще
Минимум два варианта:
std::cout << "Yeah baby!" << std::endm; // some kind of "end message" manipulator


static_cast<void>(std::cout << "Yeah baby!");


В обоих случаях мы выражаем намерения явно. Есть еще вариант приведения в стиле С к (void), ИМХО такое приведение надо было пристрелить еще в прошлом стандарте С++ и не вспоминать о нем. А то оно имеет слишком свободное поведение: может работать как const_cast, static_cast, reinterpret_cast, как вызов конструктора, и, самое главное, не ищется полнотекстовым поиском по коду никак вообще. Гадость, одним словом.


J>Только это не поможет. Ну денется результат куда-то, как ты застрахуешь программера от того, что он потом не перепутает s1 и s2, которые ты заставил его создать?


Это верно и сейчас для всех случаев, где s1 и s2 одного типа. Логический вывод из этого — нужно плодить типы. Усугубить еще больше использованный нами подход. Вот абстрактный пример, где нужны два аргумента, принадлежащие одной и той же стадии протокола:
template<int Version>
class ProtocolData { 
private:
  ProtocolData(int value) {}

public:
  ProtocolData(const ProtocolData &) {}

  friend class Protocol;
};

class Protocol {
public:
  ProtocolData<1> Init(const std::string & host);
  
  template<int Version>
  ProtocolData<Version+1> next(ProtocolData<Version> data) {...}

  template<int Version>
  void exchange(ProtocolData<Version> a, ProtocolData<Version> b) {...}
};

...

Protocol protocol;

auto a = protocol.Init("host-a"); 
auto b = protocol.Init("host-b");

protocol.exchange(a, b); // OK

auto a1 = protocol.next(a);
auto b1 = protocol.next(b);

protocol.exchange(a1, b/*1*/); // Compilation error



==========
На остальное чуть позже отвечу.
Re[41]: Интерфейс vs. протокол.
От: Pavel Dvorkin Россия  
Дата: 19.04.11 12:11
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Если можешь объяснить (на пальцах), как это должно компилироваться и работать (пример, который я привел) — объясни. Если нет — закончим дискуссию.


H>А как вообще работает вывод типов в языках?

H>Или он тоже не работает в "условиях в реальных проектов"?

Как работает вывод типов в основных языках — объяснять не надо, а вот какая от этого может быть польза в том примере, который я привел — объясни. Если бы я эту программу писал — поставил бы float и на этом вывод типов бы закончился. Проверки компилятором сводились бы к коректности употребления float в том или ином месте. Мне говорят — можно и больше проверок компилятором, будет польза. Можешь — объясни, на этом примере.
With best regards
Pavel Dvorkin
Re[12]: Интерфейс vs. протокол.
От: vdimas Россия  
Дата: 19.04.11 22:12
Оценка:
Здравствуйте, jazzer, Вы писали:

J>Она не завернута явно, но твои InitialPtr, OpenPtr и ClosedPtr — это же состояния КА, так что хоть горшком назови


Это просто состояния.
Понятное дело, что любой объект это и есть автомат. Разница тут лишь в присутствии/отсутствии ограничений на формат сигналов. ИМХО, обычный вызов методов всяко удобнее специальных go_transition.

V>>Для случая файла на порядок дешевле создать в куче некий "shared object", чем делать DuplicateHandle/CloseHandle в каждом конструкторе копирования и деструкторе состояния Opened.

J>А у меня этого и нету, это у тебя file передается, по-разному обернутый, а у меня передается его состояние, которое с тем, кто и как владеет файлом, никак не связаны. А у тебя смешано владение и состояние.

Дык, у тебя-то состояние разнесено по 2-м сущностям — по File, и по его "дополнительному" состоянию. Т.е. получить некое состояние и куда-то передать не получится, тебе надо будет передавать пару: объект, инкапсулирующий логику слежения за ресурсами, и текущее его вспомогательное состояние. Мне это кажется малость перебором, пусть это "дополнительное" состояние как-нить внутри хранит ссылку на "основное". Отсюда и пляски со смарт-поинтерами.

J>А контроль ресурсов мне тут не нужен, не понимаю, почему ты так на него напираешь.


Он "не нужен" если все происходит в одном scope. Но так бывает редко.

J>Чем тебя не устраивает вызов f.go( s, Read{data_to_read} )? Что ты там хотел, буфер передавать с размером? Тогда это будет выглядеть так: f.go( s, Read{&buffer, size} ).


Ну... Если я в каждой строчке своей программы буду писать f.go(), чтобы вызывать каждый метод каждого объекта — я лучше застрелюсь.

J>Еще как воткну, ты думаешь, я только на operator<< тестировал? Ты просто не знаешь силы variadic macros. Вообще говоря, единственное, что может сломать макрос — это запятая, которая неизбежно увеличивает количество параметров. Отсюда весь гемор. С появлением variadic macros этой проблемы больше нет.


Я даже боюсь предположить, сколько мне ждать, чтобы эта же фича появилась в MS VC++.

V>>Для того, чтобы твоё s3 нельзя было переиспользовать после Close(). Да, тоже притянутость за уши, согласен, но тут иначе никак. У тебя сей момент вообще не контролируется, т.е. в случае ошибки при вызове методов для закрытого файла диагностировать это в общем случае будет труднее. А у меня задуман как бы специальный smart-pointer, который выплюнет ошибку вроде "нарушение протокола".

J>Да ладно. Сам файл в состоянии в рантайме проконтролировать, что его уже закрыли, и бросить исключение, точно так же, как это делается сейчас. Никакой разницы с твоим обнулившимся указателем, который точно так же проверяется в рантайме.

С файлом согласен, а в другом месте с диагностикой будут проблемы. В принципе, настаивать не хочу, костыль он и в Африке костыль.

V>>Уникальность, как уже сказал — это единственный способ гарантировать протокол. Ввиду того, что уникальность в С++ не подерживается, был предожен этот костыль.

J>Битва костылей

Да какая там битва? Ленивое ими помахивание.

J>Ну вот припиши внешний go_chain в твоей схеме, чтоб была ошибка компиляции, и сравним.

J>В моей это делается тремя строчками, см. мое исходное сообщение. Как это сделать просто в твоей — я не вижу.

Я новые фичи даже еще не пробовал ни разу, и пока в скепсисе, бо собирать проекты надо как для виндовых, так и для линуховых клиентов. Обхожусь для частичного примерения boost::bind/boost::function, вполне прокатывает.

Можно в итоге сделать так:
struct File { std::string fname; int handle; }; 
File openFile(const std::string & path);
File readFile(File file, void * bufer, size_t count);
void closeFile(File file);

int main(int argc, char* argv[])
{
  using namespace boost;

  char buffer[1024];

  function<void(string)> processFile = 
    call_chain
      >> bind(openFile, _1)
      >> bind(readFile, _1, buffer, sizeof(buffer))
      >> bind(closeFile, _1);

  processFile("some.path");
  return 0;
}


call_chain — небольшая однократно-писанная инфраструктура на три десятка строк на базе boost::bind/boost::function<>.


J>>>Цепочки вообще гораздо безопаснее, так как гарантируют не только правильность порядка вызовов, но и то, что цепочка применяется к одному и тому же объекту, исключая целый класс копи-пейстных ошибок типа


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

Заметь, тут функциональный подход малость удобнее, коль речь заходит о "цепочках" вызовов и комбинаторах, бо надо создавать лямбды, которые будут "звенья" этой цепи.
Re[42]: Интерфейс vs. протокол.
От: VoidEx  
Дата: 21.04.11 05:18
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


VE>>Выберу третье: могу, но не буду. Я считаю, что самостоятельный человек должен уметь сам извлекать информацию. Если не может — он идиот, и не стоит на него тратить время. Если может, но не делает, — значит не хочет, и тоже не стоит тратить на него время. Вот если бы информация была недоступна или чересчур сложна, был бы другой разговор.


PD>Самостоятельный человек , прежде чем выбирать информацию, должен убедиться в том, что она может быть ему полезной.

Ну раз ты задаешь вопрос, а тебе говорят, что ответ есть в статье, как сам думаешь, может ли быть информация полезной? Окажется ли она в самом деле полезной — это уже потом будет ясно, после прочтения.

PD>В противном случае он рискует выбрать массу бесполезной информации.

А в твоём случае он гарантирует себе остаться без полезной.
Что лучше, иногда потратить время впустую или никогда не тратить его на полезное?

PD> Вот для этого форумы и нужны — они позволяют объяснить в нескольких словах самостоятельному человеку, в чем эта информация заключается и почему она может быть полезной.

Тебе объяснили, чем она может быть полезна. Саму информацию пережёвывать уже не дело форума.

PD>На этом, как говорили раньше, позвольте откланяться, примите и проч.

Доброго дня.
Re[10]: Интерфейс vs. протокол.
От: . Великобритания  
Дата: 24.04.11 15:37
Оценка:
On 16/04/11 13:50, Pavel Dvorkin wrote:
> ИМХО все это чистый академизм, не имеющий отношения к реальной работе.
А где границу академичности провести? Скажем, а накой нужны типы вообще? Кто придумал эту гадость с string, integer, float? Была у нас функция, которая брала температуру в градусах
func(integer t)
потом вдруг выяснилось, что температура-то может быть не целой и должны писать
func(float t)
а потом и кто-то решил вводить значения "дубак", "жара", "брр.." и нам надо уже
fuct(string t)
?
Эти все типы тоже чистый академизм? Надо писать всё на асме, где у тебя есть лишь адрес ячейки в памяти?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.