OberonCore :: - Сильная типизация против сильного тестирования

... протокол сводится к ... алгоритмизации...

Владимир Лось писал(а):

То есть:

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

А Вам лично предоставляется почётное право скрестить boost::Spirit & boost::Statchart...

Для меня пока неочевидна практическая ценность подобной декларации интерфейсов.

Можно пример такого интерфейса компонента, динамика взаимодествия с которым плохо выражается традиционными средствами и становится кристально ясной при "протокольном" описании?

"Виноград зелен!" ? :twisted:

См., например, описание Zonnon-а или Composita...

А как "кристально ясно" ДИНАМИКА ВЗАИМОДЕЙСТВИЯ выражется "традиционными средствами", без привлечения доп. документации и средств разработки/проектирования, кроме собственно программного текста???

описание Zonnon-а или Composita...

Динамика взаимодействия-то явно не специфицируется нигде. Специфируется только "алфавит" и "лексика" взаимодействия.

Ну, ёлки-палки, любое клиент-серверное взаимодействие так разложите )

Илья Ермаков писал(а):

Ну, ёлки-палки, любое клиент-серверное взаимодействие так разложите )

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

Но все это должно имет какой-то практический выхлоп? Сама по себе идея ... конечно интересна, но хочется посмотреть на практическое применение.

Такое впечатление, что Вам просто доставляет удовольствие приходить и "пёрышком в ноздрю" лазить...

Вам лично какие примеры нужны?

Идёте на сборник документов rfc

Теперь представьте, как меньше было бы ошибок реализации логики взаимодействия, имей реализаторы набор просто ЯЗЫК ПРОГРАММИРОВАНИЯ, позволяющий вносить декларации взаимодействия в текст и гарантирующий проверку соблюдения объявленных протоколов...

То, что Вы успешно освоили и пользуетесь технологиями вчерашнего и сегодняшнего дня, нисколько не даёт Вам право, за личиной "непонимания" ради чего кто-то пытается применить что-то новое, охаивать и поносить сообщество!

Нет, просто прежде чем что-то отрезать (скрещивать boost::spirit и boost::statechart), предпочитаю тщательно отмерять.

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

Еще дальше послали. Туда я уже не пойду.

Да, наверное было бы круто. Но мне не кажется, что композита подходящий вариант для подобных выкладок.

Автор:	Илья Ермаков [ Вторник, 20 Январь, 2009 14:22 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Да-да-да! А протокол сводится к ещё более базовым понятиям алгоритмизации... И в итоге - уму непостижимо, сколько окольных велосипедных троп натоптано в ИТ )))

Автор:	Wlad [ Вторник, 20 Январь, 2009 14:40 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Лучше так: Илья Ермаков писал(а): ... протокол сводится к ... алгоритмизации... Потому, как само описание протокола уже предопределяет реализацию (костяка) действий по его поддержанию...

Автор:	Илья Ермаков [ Вторник, 20 Январь, 2009 15:17 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Именно так

Автор:	Wlad [ Вторник, 20 Январь, 2009 16:04 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Илья Ермаков писал(а): Именно так А теперь лёгкое движение руки приводит к смычке средств декларации и описания состояний... Только смотреть надо на "оси" состояние/входное воздействие не со стороны разбора входных сигналов по отношению к состоянию (находимся там-то, как реагировать в этом случае на пришедшее воздействие?), а - ко входу (пришло тот-то, а где мы находимся, что бы как-то среагировать?)... То есть: первый подход: Код: while( ! quit ) { read_chanel( input ); switch( state ) { case STATE_1: switch( input ) { ... } case STATE_N: ... } ... } второй подход: Код: while( ! quit ) { read_chanel( input ); switch( input ) { case DATA_1: switch( state ) { ... } case DATA_M: ... } ... }

Автор:	Vlad [ Вторник, 20 Январь, 2009 16:49 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Владимир Лось писал(а): То есть: Я правильно понял, что это все тот же парсер заданной грамматики, у которого на входе сообщения? Или есть какие-то принципиальные отличия? А грамматика - интерфейс объекта? И никто еще не замутил какую-нибудь библиотеку на традиционных языках?

OberonCore https://forum.oberoncore.ru/

Сильная типизация против сильного тестирования https://forum.oberoncore.ru/viewtopic.php?f=27&t=1310	Страница 4 из 5

Автор:	Wlad [ Вторник, 20 Январь, 2009 17:19 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Vlad писал(а): Владимир Лось писал(а): То есть: Я правильно понял, что это все тот же парсер заданной грамматики, у которого на входе сообщения? Или есть какие-то принципиальные отличия? А грамматика - интерфейс объекта? И никто еще не замутил какую-нибудь библиотеку на традиционных языках? Правильно. А Вам лично предоставляется почётное право скрестить boost::Spirit & boost::Statchart... Тока учтите, Вы должны обеспечить механизмы соблюдения протокола обмена в компал- И в ран- тайме (порядок прихода аргументов в соответствии с описанием протокола, их тип, домены значений. В ОБЕ стороны! )

Автор:	Vlad [ Вторник, 20 Январь, 2009 17:47 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Владимир Лось писал(а): А Вам лично предоставляется почётное право скрестить boost::Spirit & boost::Statchart... Для меня пока неочевидна практическая ценность подобной декларации интерфейсов. Можно пример такого интерфейса компонента, динамика взаимодествия с которым плохо выражается традиционными средствами и становится кристально ясной при "протокольном" описании?

Автор:	Wlad [ Вторник, 20 Январь, 2009 18:03 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Vlad писал(а): Для меня пока неочевидна практическая ценность подобной декларации интерфейсов. "Виноград зелен!" ? Vlad писал(а): Можно пример такого интерфейса компонента, динамика взаимодествия с которым плохо выражается традиционными средствами и становится кристально ясной при "протокольном" описании? См., например, описание Zonnon-а или Composita... А как "кристально ясно" ДИНАМИКА ВЗАИМОДЕЙСТВИЯ выражется "традиционными средствами", без привлечения доп. документации и средств разработки/проектирования, кроме собственно программного текста???

Автор:	Vlad [ Вторник, 20 Январь, 2009 18:44 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Владимир Лось писал(а): "Виноград зелен!" ? Что вы так вечно воинственно настроены? Я не сказал, что виноград зелен. Я сказал, что не вижу какой он. Покажите поближе. Владимир Лось писал(а): См., например, описание Zonnon-а или Composita... Уж послали так послали. Ладно, посмотрю. Владимир Лось писал(а): А как "кристально ясно" ДИНАМИКА ВЗАИМОДЕЙСТВИЯ выражется "традиционными средствами", без привлечения доп. документации и средств разработки/проектирования, кроме собственно программного текста??? Гхм. Код: o = get_object(); o.method1(); o.method2(); Есть объект. Ему посылается сообщение method1, затем method2. Какие в этом примере проблемы с динамикой?

Автор:	Valery Solovey [ Вторник, 20 Январь, 2009 19:28 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Похоже, это и есть второй способ.

Автор:	Vlad [ Вторник, 20 Январь, 2009 19:52 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Владимир Лось писал(а): описание Zonnon-а или Composita... Посмотрел. Возьмем за основу такой интерфейс: Код: INTERFACE HotelService; { IN CheckIn ( OUT AssignedRoom { IN EnterRoom IN ExitRoom } IN CheckOut OUT Bill [ IN DirectPayment ] \| OUT FullyBooked ) } END HotelService; Вот традиционный подход: Код: interface HotelService { AssignedRoom CheckIn() throw(FullyBooked); Bill CheckOut(AssignedRoom); }; interface AssignedRoom { void EnterRoom(); void ExitRoom(); }; interface Bill { void DirectPayment(); }; На мой взгляд "динамика" в традиционном варианте обозначена вполне ясно. Покритикуйте.

Автор:	Vlad [ Вторник, 20 Январь, 2009 20:09 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Илья Ермаков писал(а): Ну, ёлки-палки, любое клиент-серверное взаимодействие так разложите ) Это предложение или утверждение? Если предложение, то я по-прежнему жду пример такого взаимодействия, где традиционный подоход будет коряв. Если утверждение, то к чему весь сыр-бор?

Автор:	Wlad [ Вторник, 20 Январь, 2009 20:24 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Vlad писал(а): Илья Ермаков писал(а): Ну, ёлки-палки, любое клиент-серверное взаимодействие так разложите ) Это предложение или утверждение? Если предложение, то я по-прежнему жду пример такого взаимодействия, где традиционный подоход будет коряв. Если утверждение, то к чему весь сыр-бор? ПОслушайте, Vlad, я не воинственен! Такое впечатление, что Вам просто доставляет удовольствие приходить и "пёрышком в ноздрю лазить"... Вам лично какие примеры нужны? Идёте на сборник документов rfc (как пример явного частого описания взаимодействия - вот уж просто описания диалогов!) и смотрите, как там народ почти в каждом документе подобные описания применяет...) Теперь представьте, как меньше было бы ошибок реализации логики взаимодействия, имей реализаторы просто ЯЗЫК ПРОГРАММИРОВАНИЯ, позволяющий вносить декларации взаимодействия в текст и гарантирующий проверку соблюдения объявленных протоколов... Приведённый Вами пример - примитивен. Один-в-один. Без возможной промежуточной логики формирования "вопрсов" и "ответов". А логика может быть чрезвычайно запутанной... И Вы всегда взмози отыскать в "макаронинах" текстовки правильное расположение операторов, формирующих обмен по протоколу???

Автор:	Wlad [ Вторник, 20 Январь, 2009 20:41 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Vlad писал(а): Но все это должно имет какой-то практический выхлоп? Сама по себе идея ... конечно интересна, но хочется посмотреть на практическое применение. Вапсчето говоря, очень мне это напоминает дискуссии во времена раннего внедрения ООП... Vlad, никогда не хотели оказаться в роли общепризнанного ретрограда? То, что Вы успешно освоили и пользуетесь технологиями вчерашнего и сегодняшнего дня, нисколько не даёт Вам право, за личиной "непонимания" ради чего кто-то пытается применить что-то новое, охаивать и поносить сообщество! То, что Вы с таким воодушевлением выдаёте за что-то грандиозно-всеобщеспасительное (и - окончательно-правильно-выбранное), ВЧЕРА ещё поносилось тогдашними подобными Вам (только тогда они "на отлично" ориентировались в модификациях Фортрана, его библиотеках и пакетных командах Примуса на ЕСках)...

Страница 4 из 5	Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/

Автор:	Vlad [ Вторник, 20 Январь, 2009 20:50 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Владимир Лось писал(а): Такое впечатление, что Вам просто доставляет удовольствие приходить и "пёрышком в ноздрю" лазить... Нет, просто прежде чем что-то отрезать (скрещивать boost::spirit и boost::statechart), предпочитаю тщательно отмерить. Владимир Лось писал(а): Вам лично какие примеры нужны? Примеры "нетрадиционного" описания интерфейсов, которые позволяют понять как функционирует система лучше, чем в случае "традиционного" описания. Владимир Лось писал(а): Идёте на сборник документов rfc Еще дальше послали. Туда я уже не пойду. Владимир Лось писал(а): Теперь представьте, как меньше было бы ошибок реализации логики взаимодействия, имей реализаторы набор просто ЯЗЫК ПРОГРАММИРОВАНИЯ, позволяющий вносить декларации взаимодействия в текст и гарантирующий проверку соблюдения объявленных протоколов... Да, наверное было бы круто. Но мне не кажется, что композита подходящий вариант для подобных выкладок.

Автор:	Wlad [ Вторник, 20 Январь, 2009 21:05 ]
Заголовок сообщения:	Re: Сильная типизация против сильного тестирования
Vlad писал(а): Нет, просто прежде чем что-то отрезать (скрещивать boost::spirit и boost::statechart), предпочитаю тщательно отмерять. Но складывается впечатление, что Вы и "отмерять"-то САМИ не хотите... Вы постоянно просите, что бы Вам "разжевали и в рот положили"... Владимир Лось писал(а): Примеры "нетрадиционного" описания интерфейсов, которые позволяют понять как функционируется система лучше, чем в случае "традиционного" описания. Ну да, а то, что городится огород с UML, BOM-ом, диаграммами а ля Дракон, это Вам - не доказательство?! Сам факт производства таких усилий? А "нетрадиционность"-то описания деклараций - В ЧЁМ? Тот же текст, та же "РБНФ-истость" деклараций... В чёсм ваши сомненья и недоверия? В том, что в языке нужна реализация поддержки и рухнет нужность системы ваших знаний по традиционному вороху средств? Владимир Лось писал(а): Еще дальше послали. Туда я уже не пойду. О, Господи! Вам нужна была иллюстрация, непосредственно "из жизни"? Уж то, что непосредственно, касающиеся любимого нами всеми интернета и сетевых технологий, Вам не нравится??? - Ваше дело и ваши проблемы! Анализ я за Вас провести у Вас в голове не могу... Владимир Лось писал(а): Да, наверное было бы круто. Но мне не кажется, что композита подходящий вариант для подобных выкладок. А на чём это "кажущность" основана? Вот я, например уверен, что - как раз подходит! Там средство для такого описание есть и оно верифицируемо (компайл- + реал- тайм). Вы можете такое сделать на Си++ или указать на готовое решение? Нет! И не сможете никогда (без изменения кардинального языка Си++).