эдакий эгоистичный опенсорс

ребят, подскажите, как вы прокачиваете свой github? как проекты находите для внесения правок? хочу начать в опен-сорс

Допиливаю чем пользуюсь и делаю то, чего не хватало.

эдакий эгоистичный опенсорс

а он ты думал чисто альтруистичный?)

а он ты думал чисто альтруистичный?)

ну там все пишут, типа ищите проекты, в которых нужны люди, меинтейните старые, траляля

но я чёт таких людей не знаю)

это реально удобнее промисов

Серега, это немного другой вопрос. Изначально срач начался из-за "не, я реакт выпилю как только время появится амп возьму. в попу этот a+ промисовый ад" - челик утверждает что реакт говно, потому что callbackhell, при этом сбрасывает свою либу как аргумент .... не может развернуть все в одну цепочку. Вот и получается, советчик от бога: как работает цепочка промисов не разобрался, но вещает что говно А по поводу удобнее или нет - субьективно, ведь все-равно ты оборачиваешь какими-то дополнительными вызовами. Вот была бы нативная поддержка как async/wait - тут вопросов бы не было вообще )))

Реакт говно) и с этим спорят ток упоротые)

Серега, это немного другой вопрос. Изначально срач начался из-за "не, я реакт выпилю как только время появится амп возьму. в попу этот a+ промисовый ад" - челик утверждает что реакт говно, потому что callbackhell, при этом сбрасывает свою либу как аргумент .... не может развернуть все в одну цепочку. Вот и получается, советчик от бога: как работает цепочка промисов не разобрался, но вещает что говно А по поводу удобнее или нет - субьективно, ведь все-равно ты оборачиваешь какими-то дополнительными вызовами. Вот была бы нативная поддержка как async/wait - тут вопросов бы не было вообще )))

он то разобрался, просто он драматизирует. Промисы это реально "чуть лучше" чем вложенные колбэки (и твой пример с передачей по ссылке всяких штук и действием на расстлянии это только подтверждает). > субьективно, ведь все-равно ты оборачиваешь какими-то дополнительными вызовами. конечно субъективно, все упирается в ментальную модель пользователя. Подавляющее большинство привыкло к синхронному флоу выполнения и обработке ошибок через try/catch. Промисы позволяют тебе выразить пайплайн как цепочку действий. Елды же позволяют эту цепочку действий записать в синхронном стиле. И это пиздец важная штука.

> Вот была бы нативная поддержка как async/wait - тут вопросов бы не было вообще ))) были бы

предположим у нас есть 5 функций в цепочке вызовов

f1, f2, f3, f4, f5, f6

и где-то у нас записано const a = f1(). Вдруг оказалось что f6 надо сделать запрос на сервер - не вопрос, достаточно вроде бы написать просто const a = await f1() но нет... надо явно указать что f1 асинхронная, так же и для f2 и f3 и всех функций в цепочке вызовов.

> Вот была бы нативная поддержка как async/wait - тут вопросов бы не было вообще ))) были бы

Конечно, вопросы были бы, но на данный момент, с yield все то же самое + функция обертка.

Конечно, вопросы были бы, но на данный момент, с yield все то же самое + функция обертка.

Именно так. А теперь представь как пример с f1, f2, f3, ... f6 раздулся бы из-за промисов)

так что yield и обертки это все еще лучше промисов

но чуть хуже async/await на уровне языка

так что.... "в жопу промисы если это возможно"

Боря, у тебя синдром пхпшника) спустись на землю. А то такое ощущение, что только ты осознаёшь, как промисы работают :)

так что с этой позиции переход на amp где в целом все построено на yield и "обертки" особо не нужны - в целом логичный шаг

мне тоже amp нравится больше чем reactphp

мне тоже amp нравится больше чем reactphp

Ты просто в промисы не можешь)

так что yield и обертки это все еще лучше промисов

Вот реально не вижу разницы, тебе в обоих случаях с f1,f2 (вообще, что это за пример через запятую.... не понятно немного) нужно оборачивать либо в yieid async() либо в ->then(function(){ Ну реально одинаково дерьмовые варианты. Тогда просто нужно топить "нахер асинхронность" - тут вот соглашусь

Ты просто в промисы не можешь)

здрасте, 3 года ими обмазывался.

здрасте, 3 года ими обмазывался.

это был сарказм, если что)

Вот реально не вижу разницы, тебе в обоих случаях с f1,f2 (вообще, что это за пример через запятую.... не понятно немного) нужно оборачивать либо в yieid async() либо в ->then(function(){ Ну реально одинаково дерьмовые варианты. Тогда просто нужно топить "нахер асинхронность" - тут вот соглашусь

try { $connection = yield connect(); } catch (ConnectionException $error) { // process error. }

Лучше глянь ссылки что я тебе вчера скидывал в тему про синглтон и event store)

разница, координальная, в том как именно записана цепочка действий

и что ты можешь с этим сделать

с промисами ты... ничего не можешь сделать. ты можешь просто ограничить глубину колбэков до 1-ого уровня. Но 1 уровень колбэков у тебя остается. с yield ты "приостанавливаешь" поток упралвения, так что у нас вообще нет колбэков.

Лучше глянь ссылки что я тебе вчера скидывал в тему про синглтон и event store)

ой не работать надо

скинь в личку

Вот реально не вижу разницы, тебе в обоих случаях с f1,f2 (вообще, что это за пример через запятую.... не понятно немного) нужно оборачивать либо в yieid async() либо в ->then(function(){ Ну реально одинаково дерьмовые варианты. Тогда просто нужно топить "нахер асинхронность" - тут вот соглашусь

yield async() это не так страшно, особенно учитывая всякие композиции функций и т.д.

с промисами ты... ничего не можешь сделать. ты можешь просто ограничить глубину колбэков до 1-ого уровня. Но 1 уровень колбэков у тебя остается. с yield ты "приостанавливаешь" поток упралвения, так что у нас вообще нет колбэков.

Бро, это я понимаю. Но теперь в своем же примере, ты не можешь вернуть $connection вверх по стектрейсу (ведь у тебя асинхронность, и там поток вызова уже убежал) не можешь перебросить throw $e дальше (по той же причине) все что ты можешь, это идти дальше В ЭТОЙ функции + ты не можешь "починить" промис через ->onFailure коллбек (Иногда это нужно, например function($exception){return "defaultValue"}), чтобы на следующем шаге пришел defaultValue...

Бро, это я понимаю. Но теперь в своем же примере, ты не можешь вернуть $connection вверх по стектрейсу (ведь у тебя асинхронность, и там поток вызова уже убежал) не можешь перебросить throw $e дальше (по той же причине) все что ты можешь, это идти дальше В ЭТОЙ функции + ты не можешь "починить" промис через ->onFailure коллбек (Иногда это нужно, например function($exception){return "defaultValue"}), чтобы на следующем шаге пришел defaultValue...

ммм почему не могу? все я могу

Вот давай для примера обернем все эти асинхронные функции внутрь doSmthgAsync(); внутри хочешь елды, хочешь промисы... не важно, внутри сделай echo "Foo" через 5 секунд. $bla = doSmthngAsy(); echo "Bar"; Скрипт выведет BarFoo и переменная $bla будет промисом (даже с yield в amphp это промисы).

Вот давай для примера обернем все эти асинхронные функции внутрь doSmthgAsync(); внутри хочешь елды, хочешь промисы... не важно, внутри сделай echo "Foo" через 5 секунд. $bla = doSmthngAsy(); echo "Bar"; Скрипт выведет BarFoo и переменная $bla будет промисом (даже с yield в amphp это промисы).

ну да, тип того

$bla = yield doSomethingAsy(); echo "Bar"

будет BarFoo

Нееет вот как ты записал будет FooBar

потому что yield будет ждать

Нееет вот как ты записал будет FooBar

ой...

да

чет попутал

ты типа говоришь о точке входа в приложение?)

нет, просто о любой синхронной фукнции в асинхронном приложении... Это ведь еще законно? :)

скорее умышленно неправильно готовит елды и пытается выдать это за минус

нет, просто о любой синхронной фукнции в асинхронном приложении... Это ведь еще законно? :)

законно, не вижу проблемы пока-что

$ip = yield resolveDns($host); if (someSyncFunction($ip)) { throw \Exception(); } return yield doSomethingUseful($ip);

Если ты возьмешь асинхронность(любой вариант) и вызовешь внутри любой другой синхронной функции, то синхронная функция вернет тебе промис. Следовательно, внутри этой синхронной функции что промис вей, что yield way имеют одни и те же проблемы.

какие проблемы есть в приведённом Сергеем примере? ну кроме того, что он проще записан в разы. Это большая проблема.

$ip = yield resolveDns($host); if (someSyncFunction($ip)) { throw \Exception(); } return yield doSomethingUseful($ip);

Получается, тебе вызов этой функции тоже нужно делать yield чтобы отловить этот exception вверху... А если тебе нужно продолжить работу? Можешь привести пример с FooBar и перехватом exception но с вызовом подфункций

Если ты возьмешь асинхронность(любой вариант) и вызовешь внутри любой другой синхронной функции, то синхронная функция вернет тебе промис. Следовательно, внутри этой синхронной функции что промис вей, что yield way имеют одни и те же проблемы.

ничего не понимаю

Ок, давай я скину на промисах

Получается, тебе вызов этой функции тоже нужно делать yield чтобы отловить этот exception вверху... А если тебе нужно продолжить работу? Можешь привести пример с FooBar и перехватом exception но с вызовом подфункций

заверни в try/catch

не надо на промисах)

а ты переведешь в елды

try { $ip yield resolveDns($host); } catch(UnableToResolveDNS $error) { // } // продолжаем работу

под продолжаем работу я имею ввиду вызов чего хочешь

Ребят, думаю найдутся здесь кто с хайлоадом работал. Вопрос: если сделали реплику Master-Slave, то пишем получается всегда в мастер, а читаем с мастера и слейвов? Какой на практике лаг между тем как записали в мастер и данные появились на реплики? Может такое быть, что если записал в мастер и тут же прочитал из реплики, то данные ещё старые останутся?

Я тебя прошу это спрятать в другой вызов. И сразу это вызвав отправить на экран echo "Foo"

yield (с оберткой) дожидается выполнения промиса и развораичвает его. Если тот зафэйлился - кинет исключение.

Я тебя прошу это спрятать в другой вызов. И сразу это вызвав отправить на экран echo "Foo"

ну да, там будет yield

потому что это асинхронная функция

Но с промисами ты можешь продолжать работу, и функция тоже асинхронная

yield application() echo "Bar"

Но с промисами ты можешь продолжать работу, и функция тоже асинхронная

....но с елдами ты можешь продолжать работу и функция тоже асинхронная

ничего не понимаю

ERROR: S client not available

этот человек меня промисам учить пытался...

ничего не понимаю

думаю ответ в том, что он не совсем понимает как амп резолвит

yield application(echo Foo) echo "Bar" FooBar после вызова yield application у тебя стоит поток выполнения $this->application()->then(echoFoo); echo Bar; //при необходимости echoBar BarFoo - могу продолжать писать код в then (асинхронные вызовы) могу сразу после функции (синхронный код)

Но с промисами ты можешь продолжать работу, и функция тоже асинхронная

внутри происходит что-то типа.... async(fn) { return (...args) => { promise = fn(...args) promise.then( success, failure ) } }

yield application(echo Foo) echo "Bar" FooBar после вызова yield application у тебя стоит поток выполнения $this->application()->then(echoFoo); echo Bar; //при необходимости echoBar BarFoo - могу продолжать писать код в then (асинхронные вызовы) могу сразу после функции (синхронный код)

типа ты о том что ты можешь в чепочке промисов поменять фэйл на сэксес? ты можешь это делать внутри application

внутри происходит что-то типа.... async(fn) { return (...args) => { promise = fn(...args) promise.then( success, failure ) } }

Бля, серега, сколько ты меня знаешь. Я это все перелопатил и запустил локально прежде чем вставать на скользкий путь "В интернете кто-то не прав" .... я в курсе как это все работает под капотом. Я тебе говорю что елд - это чисто сахар, который тебя ограничивает

Бля, серега, сколько ты меня знаешь. Я это все перелопатил и запустил локально прежде чем вставать на скользкий путь "В интернете кто-то не прав" .... я в курсе как это все работает под капотом. Я тебе говорю что елд - это чисто сахар, который тебя ограничивает

он меня не ограничивает нисколечки)

с промисами у меня больше контроля.

мнимого контроля

я согласен что это лишь сахар для разворачивания промисов, с этим никто не спорил вроде.

но если под копотом те же промисы и мы из просто разворачиваем - о каких таких ограничениях идет речь?

Ребят, думаю найдутся здесь кто с хайлоадом работал. Вопрос: если сделали реплику Master-Slave, то пишем получается всегда в мастер, а читаем с мастера и слейвов? Какой на практике лаг между тем как записали в мастер и данные появились на реплики? Может такое быть, что если записал в мастер и тут же прочитал из реплики, то данные ещё старые останутся?

бамп

ты что бы "заменить фэйл на сексес" всеравно должен добавить еще один then и преобразовать fail в новый промис

Ребят, думаю найдутся здесь кто с хайлоадом работал. Вопрос: если сделали реплику Master-Slave, то пишем получается всегда в мастер, а читаем с мастера и слейвов? Какой на практике лаг между тем как записали в мастер и данные появились на реплики? Может такое быть, что если записал в мастер и тут же прочитал из реплики, то данные ещё старые останутся?

да, пишем в мастер, читаем из слэйвов. У меня было лаг в пол секунды (записал, дернул api, та сходила ко мне а данных в реплике еще нет)

потому если тебе критично ты всегда для таких операций можешь читать из мастера

их обычно не очень много

да, пишем в мастер, читаем из слэйвов. У меня было лаг в пол секунды (записал, дернул api, та сходила ко мне а данных в реплике еще нет)

И как с этим бороться?

И как с этим бороться?

по идее с этим не нужно бороться.

точнее я бы сказал бесполезно, и вместо этого стоит выстраивать логику так что бы ей пофигу было (ты всегда можешь важные штуки из мастера читать)

слейв не должен использоваться как оперативная база. Вот и всё. слейв - это слейв. Его задача на подхвате сидеть

А реплика Master-Master плохая идея?

А реплика Master-Master плохая идея?

смотря какая проблема) есть вероятность что у тебя таких проблем пока нет

а значит тебе достаточно master-slave

p.s. если тебе вообще реплики нужны

я согласен что это лишь сахар для разворачивания промисов, с этим никто не спорил вроде.

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

ой красавчик

хоспаде, ну тучно синдром пхпшника :)

хоспаде, ну тучно синдром пхпшника :)

приедешь в Минск я вас сведу)

приедешь в Минск я вас сведу)

зачем?) я таких мудаков и здесь найду скок угодно)

зачем?) я таких мудаков и здесь найду скок угодно)

э не

э не

таких не найду?)

таких не найду?)

в хорошем смысле разумеется)