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

V>>Зачем??? Чистый табличный автомат хорош только для простых случаев или как автогенеренный по некоей автоматной грамматике.
S>В сложных случаях обилие классов и их методов не позволяет охватывать поведение паттерна одним взглядом, приходится многое держать в голове, либо разбираться с бумажкой, бродя по возможным переходам. Табличный подход гораздо компактнее и позволяет реюзать код в разных задачах (как в твоем примере #include "Fsm.h"). State же вынуждает под каждый автомат заводить отдельную иерархию состояний.

Ммм... Я вот уже намекал. Просто State — очередное не самое удачное название. В том примере, что я показал, возможно использовать одни и те же State для разных состояний. Т.е. реально состояний автомата может быть значительно больше, чем отличающихся объектов State. И тогда его лучше назвать не State, а Behavior. А иерархия поведений обычно довольно скромная выходит, если не надо помнить откуда мы пришли, и не вычислять, куда нам надо отсюда уходить. Например, формирование суррогатных сигналов у меня делается "автоматически" в одном месте — это просто тип входного сообщения. Т.е. прикладная логика даже этим не особо заморачивается. Просто смотрит на входные сообщения и что-то делает по одному-двум их типам, и вызывает базовый метод. Это всё. Поэтому в некоторых состояниях прикладная логика пуста — NULL, у меня там используется базовая логика лишь по формированию выходного суррогатного сигнала. Т.е. это пример одинакового поведения для разных состояний.

S>>>Только мой код позволял юзать смешанные модели (генерить события по смене состояния и по переходу).

V>>Дык, уже Мили. Все состояния у автомата могут выдавать выход, зависимый только от состояния (т.е. похожий на Мура), но в одном из состояний значение будет зависеть от входа — уже Мили. автомат Мура можно считать особым случаем Мили, наоборот — никак.
S>Верно. Это и подразумеваю под смешанными.

S>>>

S>>>    init        = { onInit,  { make_transition(success, wait_hello, onInitSuccess), other>closed } },
S>>>

V>>Дык, а зачем тогда мой onInit и NULL? Это и есть мой декларативный make_transitions, просто инициализация в стиле С. Ты лишь продублировал на методы с другими именами. У меня вместо onWaitHelloHello идет hello_reply.
S>Твой onInit вызывается при входе в состояние init. А мой onInitSuccess вызовется при переходе из init по сигналу success. коллбэк входа дает нам Мура. Коллбэк перехода — Мили. Если юзать и то и другое — будет смешанный.

Мой onInit — это не есть прикладной метод интерфейса State. Это калбек управляющей схемы, выставляющей нужный объект State для сессии. Показана часть внешней схемы — сам автомат (Мура). Выходной сигнал имеет тип Callback. Ну вот просто я так типизирован шаблонный класс. Мог бы и енумом типизировать. Показанный автомат не вызывает Callback, не умеет. Он лишь возвращает значение, соответствующее состоянию. Просто для показанного сценария это значение — адрес ф-ии. В других случаях я использую указатель на мембер, например. Это такая очередная автоматическая диспетчеризация, бо если этому автомату типизировать выход неким enum, то потом по нему надо будет опять делать switch/case в клиентском, по отношению к нему, коде. А здесь клиент просто вызывает указанную ф-ию по адресу с параметром this, если адрес не NULL, или некую общую ф-ию, если NULL. Всё.

==============
Наверно, объяснятель из меня никакой...

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

S>Попрошу тебя набросать тело функции, которая только по состоянию формирует управляющие команды для System.Net.Sockets.TcpClient.

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

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

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

V>>>Зачем??? Чистый табличный автомат хорош только для простых случаев или как автогенеренный по некоей автоматной грамматике.
S>>В сложных случаях обилие классов и их методов не позволяет охватывать поведение паттерна одним взглядом, приходится многое держать в голове, либо разбираться с бумажкой, бродя по возможным переходам. Табличный подход гораздо компактнее и позволяет реюзать код в разных задачах (как в твоем примере #include "Fsm.h"). State же вынуждает под каждый автомат заводить отдельную иерархию состояний.

V>Ммм... Я вот уже намекал. Просто State — очередное не самое удачное название. В том примере, что я показал, возможно использовать одни и те же State для разных состояний. Т.е. реально состояний автомата может быть значительно больше, чем отличающихся объектов State. И тогда его лучше назвать не State, а Behavior.
Я понял что в том примере тип у всех состояний один. Понял что там не vtbl, согласен называть его Behavior и возражаю против называния его "State"-ом.
V>А иерархия поведений обычно довольно скромная выходит, если не надо помнить откуда мы пришли, и не вычислять, куда нам надо отсюда уходить. Например, формирование суррогатных сигналов у меня делается "автоматически" в одном месте — это просто тип входного сообщения. Т.е. прикладная логика даже этим не особо заморачивается. Просто смотрит на входные сообщения и что-то делает по одному-двум их типам, и вызывает базовый метод. Это всё. Поэтому в некоторых состояниях прикладная логика пуста — NULL, у меня там используется базовая логика лишь по формированию выходного суррогатного сигнала. Т.е. это пример одинакового поведения для разных состояний.
Поведение все-таки разное (на выходе), но оно формируется не полиморфизмом, как в State, а засовыванием в "таблицу" "callback"-ов. Но сами экземпляры состояний имеют один тип, потому нет нужды плодить N классов для них. В этом плане — да, поведение их внутри машины состояний одинаковое — а именно предоставление информации по дальнейшим переходам.

S>>>>Только мой код позволял юзать смешанные модели (генерить события по смене состояния и по переходу).

V>>>Дык, а зачем тогда мой onInit и NULL? Это и есть мой декларативный make_transitions, просто инициализация в стиле С. Ты лишь продублировал на методы с другими именами. У меня вместо onWaitHelloHello идет hello_reply.
S>>Твой onInit вызывается при входе в состояние init. А мой onInitSuccess вызовется при переходе из init по сигналу success. коллбэк входа дает нам Мура. Коллбэк перехода — Мили. Если юзать и то и другое — будет смешанный.

V>Мой onInit — это не есть прикладной метод интерфейса State. Это калбек управляющей схемы, выставляющей нужный объект State для сессии. Показана часть внешней схемы — сам автомат (Мура). Выходной сигнал имеет тип Callback. Ну вот просто я так типизирован шаблонный класс. Мог бы и енумом типизировать. Показанный автомат не вызывает Callback, не умеет.
Вот как? Я подумал что он их вызывает. И мой код с make_transition был написан в предположении что автомат вызывает этот Callback в случае входа в состояние, к которому он приписан. И я предложил добавить Callback для прохода по ребру, который бы дергал автомат при переходе по ребру.
V>Он лишь возвращает значение, соответствующее состоянию. Просто для показанного сценария это значение — адрес ф-ии. В других случаях я использую указатель на мембер, например. Это такая очередная автоматическая диспетчеризация, бо если этому автомату типизировать выход неким enum, то потом по нему надо будет опять делать switch/case в клиентском, по отношению к нему, коде. А здесь клиент просто вызывает указанную ф-ию по адресу с параметром this, если адрес не NULL, или некую общую ф-ию, если NULL. Всё.
Теперь ясно.

V>Наверно, объяснятель из меня никакой...
Просто невнимательно разглядел пример. Действительно, раз Callback идет параметром шаблона, то вряд ли шаблон умеет его вызывать (если конечно не специфицирован соответствующим образом).

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

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

S>>Попрошу тебя набросать тело функции, которая только по состоянию формирует управляющие команды для System.Net.Sockets.TcpClient.

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

SW>Во вторых ты сам показал пример такой функции Чего тебе еще надо ?
Я не мог показывать пример такой функции.
Если ты об

void TCPClosed::ActiveOpern (TCPConnection* t)

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

SW>Ты не путаешь автомат с функцией ради которой реализовывался State ? Ты не забыл, в чем особенность State ?
Ты не пытаешься свое непонимание вопроса приписать мне?

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

SW>>Во первых, я уже показал подробное описание автомата.
S>В котором есть зависимость выхода от входного сигнала, которую ты усиленно отрицаешь.

см ниже.

SW>>Во вторых ты сам показал пример такой функции Чего тебе еще надо ?
S>Я не мог показывать пример такой функции.
S>Если ты об
S>

S>void TCPClosed::ActiveOpern (TCPConnection* t) 
S>

S>То это не функция формирования выходного сигнала

Эта функция и является одним из выходных сигналов.

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

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

SW>>>Во вторых ты сам показал пример такой функции Чего тебе еще надо ?
S>>Я не мог показывать пример такой функции.
S>>Если ты об
S>>

S>>void TCPClosed::ActiveOpern (TCPConnection* t) 
S>>

S>>То это не функция формирования выходного сигнала

SW>Эта функция и является одним из выходных сигналов.
Вообще нет. Это часть системы диспетчеризации. Выходным сигналом будет то, что этот метод сделает кроме смены состояния.

Но фиг с ним, это детали. А вот что важно.
Что метод ActiveOpen будет вызван при сигнале ActiveOpen.
А метод Close будет вызван при сигнале Close.
Это и есть зависимость выходного сигнала от входного.

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

SW>>Входной сигнал — это вызов метода и его параметры. Выходной — это сам метод.

V>Мимо. Сам метод — это вычисления, собсно полезная функция.

Он же выходной сигнал. Не важно, как ты хочешь его использовать.

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

SW>>Эта функция и является одним из выходных сигналов.
S>Вообще нет. Это часть системы диспетчеризации. Выходным сигналом будет то, что этот метод сделает кроме смены состояния.

Это ты хочешь её использовать таким образом. Но твои намерения не имеют никакого отношения к автомату Мура.

S>Что метод ActiveOpen будет вызван при сигнале ActiveOpen.
S>А метод Close будет вызван при сигнале Close.
S>Это и есть зависимость выходного сигнала от входного.

Это всего лишь путаница из того, что входные выходные сигналы совмещены частично. Нарисуй автомат Мура, назови входные и выходные сигналы одинаково и ты получишь ровно такую же же путаницу.

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

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

SW>>>Эта функция и является одним из выходных сигналов.
S>>Вообще нет. Это часть системы диспетчеризации. Выходным сигналом будет то, что этот метод сделает кроме смены состояния.

SW>Это ты хочешь её использовать таким образом. Но твои намерения не имеют никакого отношения к автомату Мура.
Твое понимание автомата Мура не имеет к нему отношения.

S>>Что метод ActiveOpen будет вызван при сигнале ActiveOpen.
S>>А метод Close будет вызван при сигнале Close.
S>>Это и есть зависимость выходного сигнала от входного.

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

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

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

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

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

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

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

SW>В State тоже не надо знать, по какому сигналу был или не был переход, поскольку функция привязана исключительно к состоянию. На а если ты можешь параметры использовать, то это просто хак, потому что выход совмещен со входом Раздели входы-выходы, например сделавый выходы чисто как свойства и убедись, что ничего не меняется.
Способ реализации тут совсем непричем. Забудь про паттерн State.
Есть вход
x1, x2, x3, ...
он подается на вход в некоторый ящик [], внутри которого хранится текущее состояние [s?]
из ящика вылетают сигналы y1, y2, y3, y4.
Функция, выбрасывающая сигналы из ящика, называется выходной.
Теперь смотри:
ящик в состоянии [sConnected]. В зависимости, от того, что мы в него толкнем на вход, (xClose или xSend), получим на выходе либо команду к закрытию соединения, либо команду к посылке данных (yClose или ySend соответственно) для обоих подходов. Внимание на обозначения: состояния имеют префикс s, сигналы входа — x, сигналы выхода — y.

Что происходит под полом у Мили?
Идет анализ, в каком мы состоянии и какой именно сигнал пришел, для того что бы перевести машину в новое состояние. Функция перехода у обоих автоматов одинакова и зависит от входного сигнала. У Мили точно такая же функция определяет выходной сигнал, разве что отображает она не в X, а в Y.
Т.е. в простом случае мы имеем две таблицы (могут быть не таблицы, а более сложные функции)
Одна — функция переходов
sConnected --xSend-->sConnected
sConnected --xClose-->sDisconnected

Другая — выходов
sConnected --xSend-->ySend
sConnected --xClose-->yClose

Здесь очевидно, что функция выходов зависит как от текущего состояния, так и от сигнала, который пришел извне, точно так же, как и функция переходов. Сверься с определением автомата Мили, если угодно.

В автомате Мура функция выхода не зависит от того, что толкают на вход, а зависит только от состояния автомата.
Что бы перейти от автомата Мили к автомату Мура, нужно наплодить лишних состояний. Например, нужно сделать состояние, которое будет гнать к выходу сигнал ySend.
Выглядеть это будет так:
sConnected ---xSend---> sSend
sSend---xSend--->sSend
sSend---xClose--->sDisconnected
sConnected---xClose--->sDisconnected

Функция выхода будет делать вот что:
sConnected -> yConnect
sSend-> ySend
sDisconnected -> yDesconnect

Теперь заметь разницу, между функцией перехода и функцией выхода. Первая как и у Мили, зависит и от входа и от текущего состояния. Вторая — только от текущего состояния. Сверься с определением автомата Мура.

Если ты не в силах описанное осмыслить, то найди себе того, кто это тебе объяснит. Я подопух что-то уже.

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

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

S>он подается на вход в некоторый ящик [], внутри которого хранится текущее состояние [s?]
S>из ящика вылетают сигналы y1, y2, y3, y4.
S>Функция, выбрасывающая сигналы из ящика, называется выходной.
S>Теперь смотри:
S>ящик в состоянии [sConnected]. В зависимости, от того, что мы в него толкнем на вход, (xClose или xSend), получим на выходе либо команду к закрытию соединения, либо команду к посылке данных (yClose или ySend соответственно) для обоих подходов.

Не правильно. Выход это не конкретная команда,а функция. Ты снова путаешься там же где и раньше.
Тупейший пример, который показывает,почему State это автомат Мура:
Вход — сигнал a или б. Состояния А и Б. а переключает в A, б переключает в Б. Выход — тригонометрическая функция f. В состоянии A — sin, в состоянии Б — cosin.
Что бы ты ни делал, что бы ни слал на вход, в состоянии А f=sin, а в Б f=cosin.
Путаница в State берется из за того, что вход он же и выход и он же параметр для f а значит для sin или cosin в зависимости от состояния.
То есть, как только разделили входы от выходов, автомат очевидно Мура. Что бы он стал автоматом Мили, функция f должна срабатывать только в момент конкретного переключения , то есть, здесь нужно файрить эвент.
Теперь усложним задачу — выхода ровно два, f1 и f2. В состоянии А f1 = sin,f2 = tan, в состоянии Б f1=cosin, f2=cotan.
Вопрос, какой выход будет в состоянии А ? Очевидно, f1=sin и f2=tan.
В электронике есть задающий генератор. В программухе этого нет. Потому что бы получить функцию, нужно самому обратиться к ней каким либо образом. В электронике ничего такого не нужно делать — сигнал сам по себе подаётся на шину.

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

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

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

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

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

S>>ящик в состоянии [sConnected]. В зависимости, от того, что мы в него толкнем на вход, (xClose или xSend), получим на выходе либо команду к закрытию соединения, либо команду к посылке данных (yClose или ySend соответственно) для обоих подходов.

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

S, X и Y — конечные непустые множества

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

SW>Тупейший пример, который показывает,почему State это автомат Мура:
Ошибка. Паттерн State может описывать как автомат Мура, так и автомат Мили. Я всю дорогу говорил о конкретном примере в GoF. Он — Мили.

SW>Вход — сигнал a или б. Состояния А и Б. а переключает в A, б переключает в Б. Выход — тригонометрическая функция f. В состоянии A — sin, в состоянии Б — cosin.
SW>Что бы ты ни делал, что бы ни слал на вход, в состоянии А f=sin, а в Б f=cosin.
Здесь ты описал автомат Мура.
Его таблица переходов
A -b-> B
A -a-> A
B -a-> A
B -b-> B
Таблица выходов
A — sin
B — cosin
Здесь выходной символ есть функция. точнее, множество Y = {sin, cosin}

SW>Путаница в State берется из за того, что вход он же и выход и он же параметр для f а значит для sin или cosin в зависимости от состояния.
State может выдавать любые выходные сигналы. Пример в GoF выдает команды физическому соединению в момент подачи сигнала. То что они совпали с входными — это иллюзия. Давай я входной сигнал переименую в Open, а выходной останется connection.Connect(bla-bla). Так путаница исчезла?

SW>То есть, как только разделили входы от выходов, автомат очевидно Мура. Что бы он стал автоматом Мили, функция f должна срабатывать только в момент конкретного переключения , то есть, здесь нужно файрить эвент.
Загляни в GoF, там команды соединению подаются перед переключением автомата в теле метода, вызываемого входным сигналом, а не как-нибудь еще. Есть там эвент или нет — дело десятое.

SW>Теперь усложним задачу — выхода ровно два, f1 и f2. В состоянии А f1 = sin,f2 = tan, в состоянии Б f1=cosin, f2=cotan.
На самом деле тут не 2 выхода, а один, состоящий из кортежа функций. Y = { (sin, tan), (cosin, cotan)}
Заметь, это могло бы быть
Y = { ("", 2, sin), ("5", -1, cos) }

SW>Вопрос, какой выход будет в состоянии А ? Очевидно, f1=sin и f2=tan.
Очевидно, что пара y = (sin, tan)

Теперь усложняем задачу. При сигнале a в состоянии A выдавать x^2 и оставаться на месте. При сигнале b в состоянии A переключаться и выдавать cosin. При сигнале b в состоянии B выдавать x-1, при сигнале a в состоянии B переключаться в A и выдавать sin.
т.е. таблица выходов автомата меняется на следующую:
A — a -> x^2
A — b -> cosin
B — a -> sin
B — b -> x-1
Видишь пошла зависимость от входного сигнала? Знакомься, это Мили. В GoF именно так, с той разницей что выходят не функции R->R, а команды соединению.

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

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

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

В State это функция.

SW>>Тупейший пример, который показывает,почему State это автомат Мура:
S>Ошибка. Паттерн State может описывать как автомат Мура, так и автомат Мили. Я всю дорогу говорил о конкретном примере в GoF. Он — Мили.

Мура.

SW>>Путаница в State берется из за того, что вход он же и выход и он же параметр для f а значит для sin или cosin в зависимости от состояния.
S>State может выдавать любые выходные сигналы. Пример в GoF выдает команды физическому соединению в момент подачи сигнала. То что они совпали с входными — это иллюзия. Давай я входной сигнал переименую в Open, а выходной останется connection.Connect(bla-bla). Так путаница исчезла?

Нужно разделить, а не переименовать.

SW>>То есть, как только разделили входы от выходов, автомат очевидно Мура. Что бы он стал автоматом Мили, функция f должна срабатывать только в момент конкретного переключения , то есть, здесь нужно файрить эвент.
S>Загляни в GoF, там команды соединению подаются перед переключением автомата в теле метода, вызываемого входным сигналом, а не как-нибудь еще. Есть там эвент или нет — дело десятое.

State это автомат + полезная функция. "команды соединению подаются " — это полезная функция. И когда ты вызываешь Open то сначала ты используешь Open как выход, делаешь всё что тебе надо, переключаешь состояние и выходишь.

S>Теперь усложняем задачу. При сигнале a в состоянии A выдавать x^2 и оставаться на месте. При сигнале b в состоянии A переключаться и выдавать cosin. При сигнале b в состоянии B выдавать x-1, при сигнале a в состоянии B переключаться в A и выдавать sin.
S>т.е. таблица выходов автомата меняется на следующую:
S>A — a -> x^2
S>A — b -> cosin
S>B — a -> sin
S>B — b -> x-1
S>Видишь пошла зависимость от входного сигнала? Знакомься, это Мили. В GoF именно так, с той разницей что выходят не функции R->R, а команды соединению.

Ты снова хочешь смешать все в кучу — автомат и функцию которая реализуется на этом автомате.

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

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

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

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

Но это даже не Мур. У Мура есть функция , которая у тебя напрочь отсутствует, т.е. она даже не , и не . Выход у тебя — само поведение.
Да, любой автомат в реализации State можно считать под таким углом зрения Муром. Но извини, такая интерпретация это кастрация даже для Мура. В действительностии State гораздо шире.
Берем состояния S = {s0, s1}, берем сигнал X = {тыц}, берем множество выходных сигналов Y = { 'a', 'b'}.
переходы
s0, тыц -> s1
s1, тыц -> s0
выходы
s0 -> 'a'
s1 -> 'b'

Польза от такого автомата сомнительна. Но в показательных целях сгодится. Это автомат Мура, т.к. функция выходов не зависит от входов. Заметь, я еще не реализовал его и про State ни слова не сказал. Теперь я утверждаю, что могу его реализовать паттерном State. Надеюсь, что ты не будешь оспаривать такую возможность.

Идем дальше. для описанного автомата я определяю второй сигнал. Теперь X = {тыц, бдыщ} (извиняюсь за фантазию).
бдыщ переводить не будет, но будет гадить в выход:

переходы
s0, тыц -> s1
s0, бдыщ -> s0
s1, тыц -> s0
s1, бдыщ -> s1
выходы
s0, тыц -> 'a'
s0, бдыщ -> 'b'
s1, тыц -> 'b'
s1, бдыщ -> 'a'

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

SW>>>Тупейший пример, который показывает,почему State это автомат Мура:
S>>Ошибка. Паттерн State может описывать как автомат Мура, так и автомат Мили. Я всю дорогу говорил о конкретном примере в GoF. Он — Мили.

SW>Мура.
Кастрированного Мура, или все-таки Мили.

SW>>>Путаница в State берется из за того, что вход он же и выход и он же параметр для f а значит для sin или cosin в зависимости от состояния.
S>>State может выдавать любые выходные сигналы. Пример в GoF выдает команды физическому соединению в момент подачи сигнала. То что они совпали с входными — это иллюзия. Давай я входной сигнал переименую в Open, а выходной останется connection.Connect(bla-bla). Так путаница исчезла?

SW>Нужно разделить, а не переименовать.
Нужно смотреть на выход из автомата шире, чем как на набор полезных функций.

SW>>>То есть, как только разделили входы от выходов, автомат очевидно Мура. Что бы он стал автоматом Мили, функция f должна срабатывать только в момент конкретного переключения , то есть, здесь нужно файрить эвент.
S>>Загляни в GoF, там команды соединению подаются перед переключением автомата в теле метода, вызываемого входным сигналом, а не как-нибудь еще. Есть там эвент или нет — дело десятое.

SW>State это автомат + полезная функция. "команды соединению подаются " — это полезная функция. И когда ты вызываешь Open то сначала ты используешь Open как выход, делаешь всё что тебе надо, переключаешь состояние и выходишь.
Довольно мудрено. Я рассматриваю State как просто автомат, который на выходе дает команды соединению и не несет никаких "полезных функций", ибо мне нужны команды соединению, а не полезные функции. У меня есть вход, есть выход. Что внутри — неважно. Там может быть Мили, как в GoF, может быть Мур с дополнительными состояниями.

SW>Ты снова хочешь смешать все в кучу — автомат и функцию которая реализуется на этом автомате.
Ты залип на паттерн State, и с ним связанную путаницу в своей голове. Попробуй реализовать автомат другим путем. Увидишь, что есть другие выходы, кроме как пачки "полезных функций". Да и не подходит твой "State-Мур" под формальное описание Мура.

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

V>>Наверно, объяснятель из меня никакой...
S>Просто невнимательно разглядел пример. Действительно, раз Callback идет параметром шаблона, то вряд ли шаблон умеет его вызывать (если конечно не специфицирован соответствующим образом).

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

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

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

V>>>Наверно, объяснятель из меня никакой...
S>>Просто невнимательно разглядел пример. Действительно, раз Callback идет параметром шаблона, то вряд ли шаблон умеет его вызывать (если конечно не специфицирован соответствующим образом).

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

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

SW>Он же выходной сигнал. Не важно, как ты хочешь его использовать.

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

Твои утверждения из этой ветки как раз из этого и растут, что ты отказываешь паттерну State в некоей логике вычисления полезного сигнала. Тебе кажется, что некий экземпляр State — это уже полезный сигнал сам по себе, поэтому это и есть автомат Мура. А то, что извне дергаются методы конкретного экземпляра State, якобы вообще не при чем. Ты даже предложил заменить ф-ии на св-ва. Не понимаешь принципиальной разницы?. А то, что ты своим этим предположением отвергаешь исходную постановку задачи для паттерна, и предлагаешь решать некую другую задачу вместо исходной, понимаешь?. Ведь трюк расказывает об удобной диспетчеризации функциональности через полиморфизм, через подмену экземпляра объекта с полиморфными методами. А у тебя ни полиморфизма, ни диспетчеризации, ничего. И ты заостряешься на том моменте, который с т.з. паттерна вообще не важен — это то, как мы получаем конкретный экземпляр State. Да это пофиг, на самом деле. Этот State может даже по таймеру меняться случайным образом без всяких автоматов Мура, как у меня было когда-то в одной халявке по динамическим неоновым рекламам. Обрати внимание, Мура нет, а State все еще есть.

ИМХО, это обсуждение пора уже было свернуть за бестолковостью.

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

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