Лично мне не хотелось бы что бы под моим ником публиковались не мои слова. Если кого смущает токсичность (слово то какое) комментариев может их самостоятельно через LLM прогнать вплоть до полной потери первоначального смысла
Для начала создадим базовую структуру расширения. Проект будет набором файлов:
custom_fdw.c — основной код FDW.
Makefile — для сборки расширения.
custom_fdw.control — описание расширения для PostgreSQL.
Начнем с основного файла custom_fdw.c:
На кусках custom_fdw.c всё и закончилось... Для вводной статьи не хватает информации необходимой для быстрого старта, для большого разбора тонкой механики работы FDW - очень мало информации ((
Можно наткнуться и на баги в виртуальной машине (например, проблемы с кодированием CAS-инструкций в AArch64), которые прячутся так, что их видно только в debug-билде.
Спасибо за развёрнутый ответ. У нас исключительно терменологические расхождения. Вызванный continuation - суть фрейм, а есть ли аппаратная поддержка стеков, и сколько их в реализовано в железе - штука сильно вариативная. Аллокация фрейма в хипе достаточно распространённый подход, но имеет и свои минусы - например снижение производительности при реализации stackless coroutine по сравнению с stackfull. Но без этого не реализовать замыкания. Как Вы правильно отметили, при рекурсивном вызове при невозможности оптимизации хвостовой рекурсии нет иного варианта, как плодить фреймы на каждый вызов.
Я для таких вещей использую Scheme, и никаких стековых фреймов (и вообще стека в обычном понимании) в ней нет. Зачем нужен стек в Javascript, я не знаю.
Вообще не представляю, как можно реализовать язык, поддерживающий вызов функций, без стека (фреймов или какого другого / других)
Формально у вас любой код на любом языке, в любой парадигме FSM
Вы абсолютно правы. Любой объект, меняющий своё поведение в зависимости от своего внутреннего состояния есть нечто похожее на fsm. Лично я под FSM подразумеваю подход при котором осуществляется выделение состояния в отдельный регистр, сущность. Тем более кажется несколько чужеродным применение fsm в парадигмах не предполагающих наличие скрытого состояния. Всё ИМХО.
Проблема захвата контекста вполне себе присутствует и в системах с gc. Посмотрите на оптимизации в V8, которые сделаны для того, чтобы не захватывать весь фрейм, а только нужную его часть.
Лексический контекст – это понятие времени компиляции. В рантайме здорового человека его нет.
Сложность возникает только с реализацией замыканий в языке C++ и других языков с ручным управлением памятью, так как в отсутствие сборщика мусора возникает описанная вами проблема со временем жизни переменных из внешнего лексического контекста.
Сборщик мусора здесь не причём. Проблема возникает ввиду необходимости сохранять фрейм, в котором живут захваченные переменные
Мы тут обсуждаем то, про что Кай сказал: «Я ввел такое понятие, как объект, но я имел в виду абсолютно точно не это!» (цитата по памяти).
Алан Кей говорил вообще не это: "Я придумал термин «объектно-ориентированный», и я уверяю вас, что не имел в виду C++" Про объекты он говорил, что им уделяется слишком много внимания, главное - обмен сообщениями
Вы издеваетесь? С этого начался весь разговор, а потом я триста раз то же самое повторил. Если вы считаете, что гарантии не нужны, — не смею больше отнимать время.
Код должен гарантировать, что мы может оказаться в состоянии foo тогда и только тогда, когда предыдущее состояние — bar и мы получили event baz.
Ну так осуществляйте переход в foo только в качестве реакции на event baz в состоянии bar. В нормальной реализации это самоочевидно.
Это не аргумент. Это ответ на ваше столь же бездоказательное заявление.
Какое именно? А уж по поводу меренья опытом, то в вашем списке отсутствует Smalltalk, на котором у меня имеется достаточно обширный опыт написания коммерческих систем, и без упоминания которого, как впрочем и работ Алана Кея, разговор об ООП ... (Далее про устриц от Жванецкого)
Не нужно объявлять проблемы других людей и бизнесов «несуществующими».
Эти "люди" в лице полутора местных землекопов, очевидно, не умеют готовить ООП.
ООП, как и любая парадигма, действительно требует мыслить в её рамках. Без этого - непонимание и отторжение
если моделируют бизнес требования через FSM, что приводит к комбинаторному взрыву при попытке реализовать все реальные варианты переходов.
FSM очень мощный инструмент, позволяющий решить задачу организации сложного взаимодействия, но да, это не серебряная пуля, не стоит её применять везде, где ни попадя.
А вот люди, которые профессионально за деньги писали код на дельфи, плюсах, джаве, хаскеле, руби, джаваскрипте, эрланге, эликсире (и еще некоторых других языках мимоходом) — вам говорят, что нет, не выглядит удачным, в сравнении с другими парадигмами.
Ну если люди говорят, тогда да. Не ожидал именно от Вас услышать такой аргумент
А в реальной жизни в энтерпрайзе — код разбухает в геометрической прогрессии и начинается программирование абстракций ради абстракций, чтобы заткнуть дыры применимости.
Чёт в реальном энтерпрайзе, если и есть некоторое количество систем на Haskell, то чисто следовое. Все мучаются с ООП.
Вон даже FSM с гарантиями не построить, как мы видим по примерам выше.
Какие гарантии должны быть у FSM? Отсутствие тупиковых/недостижимых стейтов? Не надо решать несуществующую проблему
Подождите, я не понимаю. Как вы разделяете, что идёт в enter «следующего» состояния, а что — в exit «предыдущего»?
Кроме переопределения реакции на внешние стимулы, у каждого стейта есть возможность переопределить действия по переходу в этот стейт и выходу из него вне зависимости от стейта, куда идёт переход (Полезно для управления стейто-контекстными счётчиками итп). В общем случае есть ещё и набор действий, осуществляемых при переходе между конкретными стейтами.
Вот у меня есть, опять же, пусть простой случай — заказ в состоянии Finalized. При переходе в состояние Paid надо проверить, что платёжные реквизиты норм, и выслать письмо покупателю. Что тут куда идёт?
Вызываем у FSM соответствующий метод. FSM вызывает аналогичный у текущего стейта. Если логика предметной части (проверка реквизитов) прошла - стейт инициирует переход в Paid. если не прошла - в Error
Кто такой fsm? Это какой-то класс-менеджер? Инстанс конкретной стейтмашины, построенной по данным бизнес-правилам?
Это инстанс конкретной fsm, с которым собственно и осуществляется взаимодействие. Стейты - приватные классы и видны исключительно внутри fsm
И когда нам захотелось перед done воткнуть стейт saving, придется поменять все классы, которые умели переходить в done, так?
Когда нам захотелось добавить новый стейт, мы:
наследуем его, переопределяем, если надо для него enter() и exit() - то что будет обрабатываться при переходе в стейт и покидании его.
дополняем fsm методом gotoSaving()
реализуем логику перехода в новый стейт, там, где это надо по задаче. Например, в некоторых местах где gotoDone() теперь будет gotoSaving()
Всё. З.Ы. Мне кажется, что наша беседа имеет некоторый привкус вкусовщины. Безусловно, на любом языке можно реализовать что угодно, и на вкус и цвет все фломастеры ... Предлагаю сойтись на тезисе, что FSM решает множество проблем и их применение в подавляющем большинстве случаев оправдано. Отдельно хочу отметить необходимость следования парадигме языка, который используется.
Человек прекрасно использует fsm с ООП, не беспокойтесь. Просто представьте, что поведение fsm определяется методами стейтов, которые за счёт полиморфизма наследования меняют свою реакцию на евенты. Никакого прямого изменения стейтов нет. Состояние скрыто. Конструкция банальна.
Лично мне не хотелось бы что бы под моим ником публиковались не мои слова. Если кого смущает токсичность (слово то какое) комментариев может их самостоятельно через LLM прогнать вплоть до полной потери первоначального смысла
На кусках custom_fdw.c всё и закончилось...
Для вводной статьи не хватает информации необходимой для быстрого старта, для большого разбора тонкой механики работы FDW - очень мало информации ((
Это шутка такая?
Надеюсь, вы возвращаете патчи в Open JDK?
Поддерживаю. А ещё использование LLM отучает думать. Но это уже реальность (((
Там народ проверил
И что может пойти не так? Код же приходит )))
(Куда катится мир?)
Спасибо за развёрнутый ответ. У нас исключительно терменологические расхождения. Вызванный continuation - суть фрейм, а есть ли аппаратная поддержка стеков, и сколько их в реализовано в железе - штука сильно вариативная. Аллокация фрейма в хипе достаточно распространённый подход, но имеет и свои минусы - например снижение производительности при реализации stackless coroutine по сравнению с stackfull. Но без этого не реализовать замыкания. Как Вы правильно отметили, при рекурсивном вызове при невозможности оптимизации хвостовой рекурсии нет иного варианта, как плодить фреймы на каждый вызов.
Вообще не представляю, как можно реализовать язык, поддерживающий вызов функций, без стека (фреймов или какого другого / других)
Вы абсолютно правы. Любой объект, меняющий своё поведение в зависимости от своего внутреннего состояния есть нечто похожее на fsm. Лично я под FSM подразумеваю подход при котором осуществляется выделение состояния в отдельный регистр, сущность. Тем более кажется несколько чужеродным применение fsm в парадигмах не предполагающих наличие скрытого состояния. Всё ИМХО.
Проблема захвата контекста вполне себе присутствует и в системах с gc. Посмотрите на оптимизации в V8, которые сделаны для того, чтобы не захватывать весь фрейм, а только нужную его часть.
Сборщик мусора здесь не причём. Проблема возникает ввиду необходимости сохранять фрейм, в котором живут захваченные переменные
Алан Кей говорил вообще не это:
"Я придумал термин «объектно-ориентированный», и я уверяю вас, что не имел в виду C++"
Про объекты он говорил, что им уделяется слишком много внимания, главное - обмен сообщениями
Ну так осуществляйте переход в foo только в качестве реакции на event baz в состоянии bar. В нормальной реализации это самоочевидно.
Взаимно
Какое именно? А уж по поводу меренья опытом, то в вашем списке отсутствует Smalltalk, на котором у меня имеется достаточно обширный опыт написания коммерческих систем, и без упоминания которого, как впрочем и работ Алана Кея, разговор об ООП ... (Далее про устриц от Жванецкого)
Так какие такие гарантии должны быть у FSM?
ООП, как и любая парадигма, действительно требует мыслить в её рамках. Без этого - непонимание и отторжение
FSM очень мощный инструмент, позволяющий решить задачу организации сложного взаимодействия, но да, это не серебряная пуля, не стоит её применять везде, где ни попадя.
Ну если люди говорят, тогда да. Не ожидал именно от Вас услышать такой аргумент
Чёт в реальном энтерпрайзе, если и есть некоторое количество систем на Haskell, то чисто следовое. Все мучаются с ООП.
Какие гарантии должны быть у FSM? Отсутствие тупиковых/недостижимых стейтов? Не надо решать несуществующую проблему
Сам концепт ООП нужен для инкапсулирования сложности. Вероятно, есть и другие методы, но ООП выглядит вполне удачным
Кроме переопределения реакции на внешние стимулы, у каждого стейта есть возможность переопределить действия по переходу в этот стейт и выходу из него вне зависимости от стейта, куда идёт переход (Полезно для управления стейто-контекстными счётчиками итп). В общем случае есть ещё и набор действий, осуществляемых при переходе между конкретными стейтами.
Вызываем у FSM соответствующий метод. FSM вызывает аналогичный у текущего стейта. Если логика предметной части (проверка реквизитов) прошла - стейт инициирует переход в Paid. если не прошла - в Error
Это инстанс конкретной fsm, с которым собственно и осуществляется взаимодействие. Стейты - приватные классы и видны исключительно внутри fsm
Когда нам захотелось добавить новый стейт, мы:
наследуем его, переопределяем, если надо для него enter() и exit() - то что будет обрабатываться при переходе в стейт и покидании его.
дополняем fsm методом gotoSaving()
реализуем логику перехода в новый стейт, там, где это надо по задаче. Например, в некоторых местах где gotoDone() теперь будет gotoSaving()
Всё.
З.Ы. Мне кажется, что наша беседа имеет некоторый привкус вкусовщины. Безусловно, на любом языке можно реализовать что угодно, и на вкус и цвет все фломастеры ...
Предлагаю сойтись на тезисе, что FSM решает множество проблем и их применение в подавляющем большинстве случаев оправдано. Отдельно хочу отметить необходимость следования парадигме языка, который используется.
Именно так. Мы же хотим переопределять поведение в зависимости от стейта. Фактически заводим объекту FSM вторую VTable
Человек прекрасно использует fsm с ООП, не беспокойтесь. Просто представьте, что поведение fsm определяется методами стейтов, которые за счёт полиморфизма наследования меняют свою реакцию на евенты. Никакого прямого изменения стейтов нет. Состояние скрыто. Конструкция банальна.