Я не это имел ввиду. Естественно я знаю и про GXT, и слегка внутри GXT. Но реализации конечного автомата там не видел. Именно на описание этой реализации я и просил линк — интересно посмотреть, как сделано у них. И сделано ли вообще, повторю, что не заметил в этой библиотеке подобных классов.
Технически – несложно. Есть три способа.
1. Один автомат в своих условиях переходов проверяет, в каком состоянии находится другой автомат. Можно делать это явно (что-то вроде a1.y() == A.READY), но обычно такие проверки спрятаны в методах – getter'ах того класса, которым управляет автомат a1.
2. Один автомат вызывает другой автомат из своих действий, выполняемых в enter() или в exit(). Как и в предыдущем случае, можно явно вызвать a1.handleEvent(), но обычно этот вызов спрятан в методах того класса, которым управляет автомат a1.
3. Третий вариант самый интересный – вложенные автоматы. Один автомат как-бы расширяет поведение другого автомата для одного (или нескольких) из его состояний. В этом случае handleEvent() одного автомата вызывается из handleEvent() другого (а также, при необходимости, и их enter() и exit()). Пример в файле FSMTestIncl.java.
Не комментировал исходя из принципа «не комментируйте очевидное». Сам по себе код там очень простой, его мало, неочевидных моментов нет. А чтобы в целом понять, как работает FSM, смотрите юнит-тесты (они, в отличие от комментариев, не врут).
Сообщество, развитие библиотеки и т.п. — это мне неинтересно. Я в данном случае просто поделился удачной идеей, но каких-либо качественных направлений в развитии библиотеки пока не вижу.
Если тебе интересно заняться централизованной поддержкой и развитием библиотеки — ничего не имею против. Могу дать доступ в проект на Google Code, а коллеги с www.devprom.net уже предлагали захостить проект у них.
Пожалуйста.
Развивать не буду, если не понадобится в рамках работы. В данный момент всего хватает.
Насчет паттерна Command, не совсем понял, что ты имеешь ввиду. Мне в голову приходит только команда, у которой в имплементации самой команды встречается вызов автомата.
Насчет аналога отката транзакций, в ИТМО народ при разработке обучающего портала для иллюстрации алгоритмов придумал делать автоматы, которые моделируют как движение «вперед» по алгоритму, так и движение «назад». На is.ifmo.ru про это когда-то давно была статья.
Шалыто не имеет к этой статье отношения. Не считая того, что он в ней упомянут.
Ну а тебе, судя по-всему, очень хотелось высказать мнение, не имеющее отношения к содержанию статьи.
> Интересно подошли к написанию робота в СПБгУ ИТМО. Танк был разработан с использованием SWITCH-технологий
Еще стоит вспомнить, что первая версия этого танка была некоторое время чемпионом мира на регулярных соревнованиях.
На этой странице, которая пропала при переходе на новую вики, было написано, что появление этого танка заставило разработчиков сменить правила игры. robowiki.net/cgi-bin/robowiki?History
Танк назывался counterwallrobot.Cynical. Его автор — я :-)
Давно дело было…
Спасибо. Зарегался и добавил в закладки.
Достоинства сервиса понятны, недостатки тоже. Возможность создания расшаренных папок порадовала. Для синхронизации использовать не буду, но применение наверняка найдется.
>>а на коммуникатор поставил OggSync.
>Зря, гугОл может синхронизировать календарь через activeSync
Я в курсе. Но опыт подсказывает, что с активсинком будет больше проблем. А я за много лет уже наелся его двоящимися событиями, удалением всех данных при удалении настроек синхронизации и прочими «удобствами».
>oggSync с какой то версии стоит денег так получается бесплатно
OggSync в базовой версии бесплатный. Платная версия отличается возможностью синхронизации контактов и возможностью синхронизации нескольких календарей.
>>Для синхронизации закладок в Firefox я использую плагин Xmarks
>а почему Google Toolbar с их закладками не используете?
Так исторически сложилось. А Google Toolbar вообще никогда не использовал.
> И еще, все конечно круто, но вам приходиться с собой таскать везде жесткий диск
Я тоже сначала опасался, что это станет проблемой. Но опыт показал, что не обязательно синхронизироваться каждый день — конфликтов получается не много. Естественно, если занимаюсь дома рабочими делами, диск приходится таскать. И если представить, что у меня есть, например, единая база кода, которую я правлю и дома, и на работе, то вариант с винчестером перестает быть интересным — но ведь это другая задача получается.
1. Один автомат в своих условиях переходов проверяет, в каком состоянии находится другой автомат. Можно делать это явно (что-то вроде a1.y() == A.READY), но обычно такие проверки спрятаны в методах – getter'ах того класса, которым управляет автомат a1.
2. Один автомат вызывает другой автомат из своих действий, выполняемых в enter() или в exit(). Как и в предыдущем случае, можно явно вызвать a1.handleEvent(), но обычно этот вызов спрятан в методах того класса, которым управляет автомат a1.
3. Третий вариант самый интересный – вложенные автоматы. Один автомат как-бы расширяет поведение другого автомата для одного (или нескольких) из его состояний. В этом случае handleEvent() одного автомата вызывается из handleEvent() другого (а также, при необходимости, и их enter() и exit()). Пример в файле FSMTestIncl.java.
Сообщество, развитие библиотеки и т.п. — это мне неинтересно. Я в данном случае просто поделился удачной идеей, но каких-либо качественных направлений в развитии библиотеки пока не вижу.
Если тебе интересно заняться централизованной поддержкой и развитием библиотеки — ничего не имею против. Могу дать доступ в проект на Google Code, а коллеги с www.devprom.net уже предлагали захостить проект у них.
Развивать не буду, если не понадобится в рамках работы. В данный момент всего хватает.
Насчет паттерна Command, не совсем понял, что ты имеешь ввиду. Мне в голову приходит только команда, у которой в имплементации самой команды встречается вызов автомата.
Насчет аналога отката транзакций, в ИТМО народ при разработке обучающего портала для иллюстрации алгоритмов придумал делать автоматы, которые моделируют как движение «вперед» по алгоритму, так и движение «назад». На is.ifmo.ru про это когда-то давно была статья.
Ну а тебе, судя по-всему, очень хотелось высказать мнение, не имеющее отношения к содержанию статьи.
Еще стоит вспомнить, что первая версия этого танка была некоторое время чемпионом мира на регулярных соревнованиях.
На этой странице, которая пропала при переходе на новую вики, было написано, что появление этого танка заставило разработчиков сменить правила игры.
robowiki.net/cgi-bin/robowiki?History
Танк назывался counterwallrobot.Cynical. Его автор — я :-)
Давно дело было…
Еще стоит вспомнить, что первая версия этого танка была некоторое время чемпионом мира на регулярных соревнованиях.
На этой странице, которую
counterwallrobot
Достоинства сервиса понятны, недостатки тоже. Возможность создания расшаренных папок порадовала. Для синхронизации использовать не буду, но применение наверняка найдется.
>Зря, гугОл может синхронизировать календарь через activeSync
Я в курсе. Но опыт подсказывает, что с активсинком будет больше проблем. А я за много лет уже наелся его двоящимися событиями, удалением всех данных при удалении настроек синхронизации и прочими «удобствами».
>oggSync с какой то версии стоит денег так получается бесплатно
OggSync в базовой версии бесплатный. Платная версия отличается возможностью синхронизации контактов и возможностью синхронизации нескольких календарей.
>а почему Google Toolbar с их закладками не используете?
Так исторически сложилось. А Google Toolbar вообще никогда не использовал.
> И еще, все конечно круто, но вам приходиться с собой таскать везде жесткий диск
Я тоже сначала опасался, что это станет проблемой. Но опыт показал, что не обязательно синхронизироваться каждый день — конфликтов получается не много. Естественно, если занимаюсь дома рабочими делами, диск приходится таскать. И если представить, что у меня есть, например, единая база кода, которую я правлю и дома, и на работе, то вариант с винчестером перестает быть интересным — но ведь это другая задача получается.