https://github.com/ircmaxell/PhpGenerics/blob/master/lib/PhpGenerics/Generator.php#L69

https://github.com/ircmaxell/PhpGenerics/blob/master/lib/PhpGenerics/Generator.php#L69

TL;DR: don't use this

TL;DR: don't use this

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

https://github.com/ircmaxell/PhpGenerics/blob/master/lib/PhpGenerics/Generator.php#L69

а die(); это будто нормально, ага

ну там кусок

но чувак же написал черная магия и вуду

еще TL:DR написал

и Item занято

Если я получаю с репозиторя даные а потом мне нужно их отсортировать, Я могу добавть в метод получения с параметр $needSort или єто обязаность сервиса и ножно передать даные ему на сортировку? как лучше организовать код?

но вообще как я уже писал скоро будет свой webpack для пхп тут Сергей даже уже кидал ссылку)

Если я получаю с репозиторя даные а потом мне нужно их отсортировать, Я могу добавть в метод получения с параметр $needSort или єто обязаность сервиса и ножно передать даные ему на сортировку? как лучше организовать код?

я бы сделал отдельный метод по получению сортированных данных по нужным полям

но это возможно не правильно

На самом деле ничего вредного в этой реализации дженериков нет. Это ж не проверки в рантайме на пыхе. Производительность проседает только при первом обращении. Дальше сбросить файл на диск, и опкеш его закешит. А так у тебя реальный дженерик. Если пишешь в strict то очень даже не плохо, лучше чем ничего

Темплейты скорее

А не генерики

На самом деле ничего вредного в этой реализации дженериков нет. Это ж не проверки в рантайме на пыхе. Производительность проседает только при первом обращении. Дальше сбросить файл на диск, и опкеш его закешит. А так у тебя реальный дженерик. Если пишешь в strict то очень даже не плохо, лучше чем ничего

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

двойной интерпретатор))

а потом запилить phparcel, phpabel...

мы вставили тебе интерпретатор в интерпретатор...

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

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

двойной интерпретатор))

так-то твой CPU это интерпритатор машинного кода. Так что, когда ты пишешь на PHP у тебя уже двойной интерпритатор Как-то ты с этим живешь )))

но вообще как я уже писал скоро будет свой webpack для пхп тут Сергей даже уже кидал ссылку)

А можно пример, для чего может понадобится webpack в php ? Я просто очень плохо себе представляю кейс, где это может пригодиться.

да это мы так, на аналогиях катаемся

тут скорее с babel проводить аналогию нужно

так-то твой CPU это интерпритатор машинного кода. Так что, когда ты пишешь на PHP у тебя уже двойной интерпритатор Как-то ты с этим живешь )))

Проц, не интерпретирует вроде, а просто исполняет инструкции.

ну тип того, бандлить php приложеия не надо

Проц, не интерпретирует вроде, а просто исполняет инструкции.

садись, два

у одного из моих преподов в универе был очень хороший вопрос на эту тему - чем компьютер от калькулятора отличается? И ответ как раз был наличие интерпритатора. Когда у тебя "инструкция" декодируется в машинную команду.

садись, два

Интерпретирует инструкции вшитые в ревизию процессора ?

Интерпретирует инструкции вшитые в ревизию процессора ?

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

А можно пример, для чего может понадобится webpack в php ? Я просто очень плохо себе представляю кейс, где это может пригодиться.

вебпак пхп это просто название интерпретатора который сделают для пхп чтобы можно было кастомный синтаксис юзать

короч причем тут webpack/babel?)

садись, два

кек- наказал ??

вебпак пхп это просто название интерпретатора который сделают для пхп чтобы можно было кастомный синтаксис юзать

как вы это любите... назвать интерпритатор в честь бандлера это то что заслуживает php

хотя по факту вам ни бандлер ни интерпритатор не нужен - вам блин транслятор нужен

https://preprocess.io/

и он уже есть

нужно только сорсмэпы допилить

и что бы ваш любимый шторм в них умел

(хотя можно просто language server запилить)

а насколько он нужен?

ну хочешь прикольный синтаксис юзаешь

не хочешь, пишешь в скучном и унылом стиле

и надо больше всяких таких штук чтобы еще несовместимо было между собой

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

так почему это интепретация, а не декодирование инструкций ?

так почему это интепретация, а не декодирование инструкций ?

что такое интерпритация?

а насколько он нужен?

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

собственно по этой причине babel так выстрелил

и сам JS так бурно начал развиваться

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

ну и да дало пинок ко всяким штукам и обкатам нового синтаксиса

1. я бы хотел возможность описывать структуры (что-то типа array shapes в hack). Сейчас такая возможность есть но без возможности референсинга на эти типы 2. я бы хотел джэнерики 3. я бы хотел короткие лямбды 4. хочу delegates on как в котлине 5. хочу дата классы которые передаются по значению (по сути обойдусь array shapes)

для всего этого придется делать либо синтаксис либо вставки на HERE/NOWDOC

ну и еще много чего можно придумать

даже такую хрень как __construct( private Foo $foo, private Bar $bar )

а для чего дата классы передающиеся по значению?

а для чего дата классы передающиеся по значению?

для того же для чего и array shapes. хочу структурный тайпинг с возможностью объявить что "вот сюда такая хрень должна придти". Есть два варианта - array shapes (структурный тайпинг) или дата классы (почти как классы но больше структуры)

в конечном счете - более дешевая опциональная имутабельность

даже такую хрень как __construct( private Foo $foo, private Bar $bar )

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

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

можешь запилить RFC, фича не очень сложная

я как-то пытался даже, но меня хватило на просто добавить возможность модификатор доступа подсовывать

ну да такая штука тоже веселит с конструктарами

генерировать свойства, конструктор и тд

можешь запилить RFC, фича не очень сложная

rfc и сразу патч) тогда вероятность что примут гораздо выше будет)

rfc и сразу патч) тогда вероятность что примут гораздо выше будет)

сначала патч и потом rfc

я б даже так делал

ERROR: S client not available

да, причем есть шанс, что нужно не один патч

+ поясняющую статью и примеры

а несколько

ибо каждый хочет по-своему видеть

формат подобных конструкторов

+ ссылки на 3v4l.org с примерами

а несколько

ну вариации синтаксиса чуть что поменять не сложно, не надо делать несколько. Лучше подумать и проработать RFC

ну и да - я думаю там будет 10% времени на продумать и реализовать и 90% сраться в комментах и в мэйлинглистах доказывая что эта фича нужна. + было бы неплохо к RFC добавить какой-нибудь фиксер (под php-cs-fixer) который автоматом в коде это поменяет

https://inviqa.com/blog/functional-programming-php-developers-guide-parser-combinators-phunkie

вот может кому-то будет интересно. Например можно отдельно в файликах какой-нибудь удобный DSL мутить

или там вдруг какой-то чужой DSL захочется попарсить

ну и да - я думаю там будет 10% времени на продумать и реализовать и 90% сраться в комментах и в мэйлинглистах доказывая что эта фича нужна. + было бы неплохо к RFC добавить какой-нибудь фиксер (под php-cs-fixer) который автоматом в коде это поменяет

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

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

нельзя, лексер/парсер php не имеет никаких точек расширений

разве?

разве

ну ок

иначе у тебя уже давно бы лежал экстеншен для async/await

иначе уже было бы сотни диалектов

кто-нибудь бы ; убрал и сделал питон из пхп. и т.п.

иначе у тебя уже давно бы лежал экстеншен для async/await

было бы неплохо)

но я чёт сомневаюсь, что оно хоть в теории в пхп появится...

но я чёт сомневаюсь, что оно хоть в теории в пхп появится...

Даже если и появится. Еще время понадобится написание либ в асинхронном стиле. Как это с питоном было впринципе, после asyncio.

Даже если и появится. Еще время понадобится написание либ в асинхронном стиле. Как это с питоном было впринципе, после asyncio.

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

Даже если и появится. Еще время понадобится написание либ в асинхронном стиле. Как это с питоном было впринципе, после asyncio.

если будет интерфейс на промисы - быстренько запилят адаптеры ко всему популярному. Это не сильно проблема

тут проблема что для большинства php разработчиков yield это колдуство прям и нипонятно

+

да штука вроде бы понятная... Непонятно - когда применять

я бы хотел на практике поюзать

так лучше всего запоминается

Генераторы чтоли ?

Генераторы чтоли ?

$generator = func(); $generator->send('foo');

вот конкретно этот аспект генераторов