«Я пишу не для славистов, я пишу для нормальных людей»
Эти методы противоречат классическому ООП: они не курочат receiver, но возвращают новый объект.
То что при "классическом ООП методы должны курочить receiver и не возвращать новый объект" даже для славистов перебор. Не думаю, что Гослинг говорил что-то в этом роде.
У Вас же огромный опыт в различных парадигмах, давайте вместе не будем называть собаку кошкой, и потом удивляться, что она лает будем настаивать на правильной терминологии. Занудность в этой области - есть гуд!
Эти методы противоречат классическому ООП: они не курочат receiver, но возвращают новый объект.
Никакому классическому ООП эти методы не противоречат. В стандартной библиотеке Smalltalk прекрасно существуют методы collect: и select: А уж более классического ООП, чем Smalltalk, придумать сложно
Кроме того, в конце формата кадра Ethernet также есть поле Frame Check Sequence, которое наряду с Cyclic Redundancy Check (CRC) используется для проверки целостности кадра.
FCS используется не "наряду с CRC" а содержит значение CRC фрейма, итп
совет - избегайте упоминания user и kernel spice вообще. К работе планировщика GO это не имеет отношения. Примените "исполнение планируется планировщиком GO или ОС"
В других материалах вы могли также видеть определения kernel space (пространство ядра) и user space (пространство пользователя). Так вот — горутины будут существовать в user space, то есть ими управляет планировщик Go (если точнее — Go Runtime), а треды в kernel space, то есть ими управляет ОС.
Упоминаемые треды существуют в user space и к kernel space не имеют отношения. И ещё много чего... Чтобы выпустить книгу потребуется хороший технический редактор.
Лично мне не хотелось бы что бы под моим ником публиковались не мои слова. Если кого смущает токсичность (слово то какое) комментариев может их самостоятельно через 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, на котором у меня имеется достаточно обширный опыт написания коммерческих систем, и без упоминания которого, как впрочем и работ Алана Кея, разговор об ООП ... (Далее про устриц от Жванецкого)
Не нужно объявлять проблемы других людей и бизнесов «несуществующими».
Это какой такой самый убогий язык?
То что при "классическом ООП методы должны курочить receiver и не возвращать новый объект" даже для славистов перебор. Не думаю, что Гослинг говорил что-то в этом роде.
У Вас же огромный опыт в различных парадигмах, давайте вместе
не будем называть собаку кошкой, и потом удивляться, что она лаетбудем настаивать на правильной терминологии. Занудность в этой области - есть гуд!Никакому классическому ООП эти методы не противоречат.
В стандартной библиотеке Smalltalk прекрасно существуют методы collect: и select:
А уж более классического ООП, чем Smalltalk, придумать сложно
Однозначно полезный перевод.
Хотя есть некоторые неточности, например:
FCS используется не "наряду с CRC" а содержит значение CRC фрейма, итп
совет - избегайте упоминания user и kernel spice вообще. К работе планировщика GO это не имеет отношения. Примените "исполнение планируется планировщиком GO или ОС"
Упоминаемые треды существуют в user space и к kernel space не имеют отношения.
И ещё много чего... Чтобы выпустить книгу потребуется хороший технический редактор.
Лично мне не хотелось бы что бы под моим ником публиковались не мои слова. Если кого смущает токсичность (слово то какое) комментариев может их самостоятельно через LLM прогнать вплоть до полной потери первоначального смысла
На кусках custom_fdw.c всё и закончилось...
Для вводной статьи не хватает информации необходимой для быстрого старта, для большого разбора тонкой механики работы FDW - очень мало информации ((
Это шутка такая?
Надеюсь, вы возвращаете патчи в Open JDK?
Поддерживаю. А ещё использование LLM отучает думать. Но это уже реальность (((
Там народ проверил
И что может пойти не так? Код же приходит )))
(Куда катится мир?)
Спасибо за развёрнутый ответ. У нас исключительно терменологические расхождения. Вызванный continuation - суть фрейм, а есть ли аппаратная поддержка стеков, и сколько их в реализовано в железе - штука сильно вариативная. Аллокация фрейма в хипе достаточно распространённый подход, но имеет и свои минусы - например снижение производительности при реализации stackless coroutine по сравнению с stackfull. Но без этого не реализовать замыкания. Как Вы правильно отметили, при рекурсивном вызове при невозможности оптимизации хвостовой рекурсии нет иного варианта, как плодить фреймы на каждый вызов.
Вообще не представляю, как можно реализовать язык, поддерживающий вызов функций, без стека (фреймов или какого другого / других)
Вы абсолютно правы. Любой объект, меняющий своё поведение в зависимости от своего внутреннего состояния есть нечто похожее на fsm. Лично я под FSM подразумеваю подход при котором осуществляется выделение состояния в отдельный регистр, сущность. Тем более кажется несколько чужеродным применение fsm в парадигмах не предполагающих наличие скрытого состояния. Всё ИМХО.
Проблема захвата контекста вполне себе присутствует и в системах с gc. Посмотрите на оптимизации в V8, которые сделаны для того, чтобы не захватывать весь фрейм, а только нужную его часть.
Сборщик мусора здесь не причём. Проблема возникает ввиду необходимости сохранять фрейм, в котором живут захваченные переменные
Алан Кей говорил вообще не это:
"Я придумал термин «объектно-ориентированный», и я уверяю вас, что не имел в виду C++"
Про объекты он говорил, что им уделяется слишком много внимания, главное - обмен сообщениями
Ну так осуществляйте переход в foo только в качестве реакции на event baz в состоянии bar. В нормальной реализации это самоочевидно.
Взаимно
Какое именно? А уж по поводу меренья опытом, то в вашем списке отсутствует Smalltalk, на котором у меня имеется достаточно обширный опыт написания коммерческих систем, и без упоминания которого, как впрочем и работ Алана Кея, разговор об ООП ... (Далее про устриц от Жванецкого)
Так какие такие гарантии должны быть у FSM?