Автор говорит о потоке исполнения и многозадачности. Крутятся ли задачи на одном ядре или на разных в данном контексте не имеет значения. Ну а stackfull сопрограммы и системные потоки семантически одно и то же.
yield и await — одно и то же. async function и generator function — тоже. Вся разниа в том, то async/await передаёт между функциями промисы, а генераторы могут передавать что угодно.
Не привязан он ни к чему. Вы так же можете возвращать типизированный промис, а внешняя функция будет вас вызывать, когда он отрезолвится.
Это делают скорее потому, что это интересная задача. У нормального разработчика это всё обычно проходит как только появляется потребность дебажить и тут выясняется, что исследовать спрятанные от себя же поля — геморрой.
Может создаваться, а может и не создаваться. Абстракцией это никак не ограничивается, что позволяет реализации самой решать, когда создавать. Inversion of Control, все дела.
Если сессия безусловно создаётся мидлварой ещё на подлёте к вашему обработчику, то имя getOrCreate врёт, так как при её вызове собственно create не происходит никогда.
Важный и совсем неочевидный вопрос: возвращаемый функцией finder делегат использует значение x, а где находится x после того, как finder вернет управление? На самом деле, в этом вопросе слышится серьезное опасение за происходящее (ведь D использует для вызова функций обычный стек вызовов): инициатор вызова вызывает функцию finder, x отправляется на вершину стека вызовов, функция finder возвращает результат, стек восстанавливает свое состояние до вызова finder… а значит, возвращенный функцией finder делегат использует для доступа адрес в стеке, по которому уже нет нужного значения! «Продолжительность жизни» локального окружения (в нашем случае окружение состоит только из x, но оно может быть сколь угодно большим) — это классическая проблема реализации замыканий, и каждый язык, поддерживающий замыкания, должен ее как-то решать. В языке D применяется следующий подход. В общем случае все вызовы используют обычный стек. А обнаружив замыкание, компилятор автоматически копирует используемый контекст в кучу и устанавливает связь между делегатом и областью памяти в куче, позволяя ему использовать расположенные в ней данные. Выделенная в куче память подлежит сбору мусора. Недостаток такого подхода в том, что каждый вызов finder порождает новое требование выделить память. Тем не менее замыкания очень выразительны и позволяют применить многие интересные парадигмы программирования, поэтому в большинстве случаев затраты более чем оправданны.
В современных реалиях правильно реализованный муж майнит число на сервере банка, а правильно реализованная жена наоборот уменьшает это число до неотрицательного значения и предоставляет сервис "борщ on demand".
Правильно реализованная жена, поддерживающая контракт "ещё борща" приготовит этого самого борща с запасом именно на случай, если я попрошу добавки. Причём с таким запасом, чтобы как бы быстро и много я ни ел, она всегда могла сгонять в Ашан за свеклой.
Давайте закончим с этой спец олимпиадой по наркоманским метафорам и попробуем понять, что вам говорит собеседник?
Автор говорит о потоке исполнения и многозадачности. Крутятся ли задачи на одном ядре или на разных в данном контексте не имеет значения. Ну а stackfull сопрограммы и системные потоки семантически одно и то же.
Не забивает, а изолирует в питомнике. Внутри питомника уже живут эти акторы.
https://github.com/tj/co/blob/master/index.js#L65
Используется ambient context с которым тоже всё элементарно.
Она не изменяет видимого состояния системы. Внутреннее состояние меняется всегда (банально пишутся логи).
Способ перенести управление во вне — это скорее генераторы. А async/await — не более чем частный их случай.
Это делают скорее потому, что это интересная задача. У нормального разработчика это всё обычно проходит как только появляется потребность дебажить и тут выясняется, что исследовать спрятанные от себя же поля — геморрой.
Может создаваться, а может и не создаваться. Абстракцией это никак не ограничивается, что позволяет реализации самой решать, когда создавать. Inversion of Control, все дела.
Надо продать этот сюжет Голивуду с интригующим названием "Borsch on Demand".
Если сессия безусловно создаётся мидлварой ещё на подлёте к вашему обработчику, то имя getOrCreate врёт, так как при её вызове собственно create не происходит никогда.
Подозреваю они на стеке такие переменные и не хранят. Либо делают как в D — в момент выхода замыкания из скоупа, переносят стек фрейм в кучу.
В современных реалиях правильно реализованный муж майнит число на сервере банка, а правильно реализованная жена наоборот уменьшает это число до неотрицательного значения и предоставляет сервис "борщ on demand".
Разумеется. Речь про те случаи, когда в сигнатуре это не отражено.
Значения математике не являются изменяемыми.
Конечно, но мы же тут играем в детективов, не мешайте.
Правильно реализованная жена, поддерживающая контракт "ещё борща" приготовит этого самого борща с запасом именно на случай, если я попрошу добавки. Причём с таким запасом, чтобы как бы быстро и много я ни ел, она всегда могла сгонять в Ашан за свеклой.
Давайте закончим с этой спец олимпиадой по наркоманским метафорам и попробуем понять, что вам говорит собеседник?
Если назовёте её deliveryMessage, то да, должна гарантировать.
Зря надеетесь. Ни производительность не вынесли, ни потребление памяти.