Контекст моей "претензии" был в сторону того, что статья позиционируется как "используем генераторы", но ни слова про то, что основная задача генераторов - это ставить выполнение функции на паузу для переключения контекста исполнения на выполнение других процессов.
А не то, что "инструмент выбран не правильно" ;)
Да, он экономит память, но это лишь побочный эффект того, что в коде не используются массивы в которых хранятся все данные выборки.
P.S. Оригинальная реализация с `while($cursor->getNext()) {}` работает ровно по такому же принципу - не создаёт массив, а каждый раз возвращает новые данные. Вот альтернативный пример как это можно делать, экономя память, вместо генераторов.
Небольшое примечание/замечание: Вообще это довольно популярное заблуждение, что yield придуман для того, чтобы экономить память. С таким же успехом можно взять обычный Iterator и в результате можем получить потребление ещё ниже, нежели в случае с генератором + выше производительность.
И хоть использование этого оператора, очевидно, удобнее, нежели писать итератор руками (или лучше просто взять готовые реализации коллекций с поддержкой функции map), однако он в первую очередь направлен на реализацию кооперативной многозадачности, которая в современно мире уходит в сторону файберов.
Поэтому, считаю, тема сисе генераторов раскрыта не до конца)
<spoiler>А вот про скругёлнные окна не надо! После скруглённых окон XP, после скруглённых окон Висты, после скруглённых окон семёрки (я уж не говорю про гном, кеды, циннамон и мой любимый буджи) приходит Win 10 и приносит с собой 2000ый год и франкиншеин‑дизайн 98ой винды, сделанный какими‑то криворукими... кхм...
В общем, Win11 с точки зрения плавности, анимашек и интерфейса в целом — прям шикарная. Этакие кеды на минималках. У каждого свои вкусы, в общем.</spoiler>
P.S. К слову о дизайне и эффективных дизайнерах, ээээм... А как сделать спойлер с оффтопом в этом новом и безусловно супер-современном текстовом редакторе хабра?))) Всё перепробовал и перетыкал уже...
Попытки натягивать сову на глобус настигали и другие языки, кто то пытается сайт на плюсах или, упаси господи, на ассемблере писать.
Тащемта написать нативное (именно нативное, а не то что в статье) приложение на PHP с нативными вызовами winapi (или чего другого) будет попроще, нежели на тех же плюсах (например). Другое дело, что в PHP просто нет экосистемы, которая бы упрощала всё это дело (вроде Qt, XAML, JavaFX, etc.), а работать с лоу-левел вызовами функций ОС — это боль.
Она не поддерживает C/C++. Так что пописать одновременно, например, на PHP и на Си (т.к. PHP поддерживает из коробки вставки на Си) не получится. Как, например, и на Java + JNI.
Вы говорите о том, что адекватный код на PHP 5.x запустится и на PHP 8.x. А автор цитаты говорил о любой совместимости, включая обратную. Мол, не надо тащить фичи 8.х, т.к. всё тоже самое можно запилить и на 5ке, которая никак "не влияет на бизнес-логику" (с).
А какая версия php сейчас в моде абсолютно не влияет на бизнес-логику.
В php 5.6 не было Throwable и было много утечек памяти в ядре (хотя вроде в 5.6 большинство как раз подлатали), следовательно надёжное websocket приложение (чат, например), реализовать практически невозможно. Ну или страдать и постоянно перезапускать его.
Или, например, задача по сложным (в т.ч. матричным) вычислениям — без компьютед-шейдеров и/или AVX через FFI в php 7.4 эффективно реализовать простыми силами не получится.
Да кучу примеров можно привести, где реализация чего-либо на "не модной" версии языка просто невозможна без дописывания этой версии языка до функционала более "модной")
React — это всего лишь библиотека для рендеринга, говорили они. React очень прост в освоении в отличие от Angular, говорили они. Делайте как мы, и всё у вас будет летать, говорили они.
Что имеем сегодня? ...
Если, кстати, говорить про фреймворки/библиотеки, то не вижу у современных библиотек рендеринга (React, Vue, etc) ни одного преимущества для построения интерфейсов против древнего как говно мамонта Knockout. Последний и намного проще в работе и изучении (ровно 3 функции нужно изучить), и гибче, и требует меньше зависимостей. Нормальных компонентов и фич шаблонизатора разве что не хватает, как у того же Vue, но в остальном — сабжи на фоне Ko выглядят как набор костылей и велосипедов.
Ну и ещё Aurelia из этого списка можно выделить, как развитие идей Ko, хоть и местами избыточный и переусложнённый.
Так и связанных списков в php нет, в чем тогда суть спора?
1) Зато есть двухсвязные из коробки.
2) Их можно реализовать и технически они в памяти будут располагаться также, как и на С. И все обращения будут идентичными.
Конечно упорядоченный. Как вы неупорядоченный кусок памяти сделаете?
Любой список как раз и выделяет память в случайных участках памяти, в отличие от массивов.
Array в PHP как раз и не является массивом, т.к. может выделить непоследовательный участок памяти, хотя в подавляющем большинстве случаев делает это последовательно:
Float тоже так хранится. Упорядоченный и неразрывный кусок памяти. Только размером меньше. Подходит под ваше определение массива? Желаете педантичности, идите до конца.
Не вижу противоречий. Float — это 1 байт, т.е. вполне себе массив из одного float или одного int8, или одного char, или двух int4 (если мы будем использовать lo + hi, как это сделано в некоторых системных апи). А ещё это может быть структурой:
Я бы согласился, если бы мы обсуждали абстрактно, а не конкретно php. В нем есть набор функций для работы utf8, никакой особой выровненной упаковки они не делают.
Для начала, ещё раз повторюсь, что в PHP нет никаких utf-8 строк. А функции на то и функции, что реализуют алгоритмы поиска, декодирования и прочих манипуляций с данными. Никто при этом не мешает хранить utf-8 строку в UCS формате и искать в ней символы за константное время, а потом обратно запаковывать. Так же как никто не мешает распаковывать в памяти RLE-сжатие, находить в нём за константное время нужный элемент, а потом опять сжимать. Это лишь вопрос реализации декодера, а не вопрос разыменования элемента из массива.
Да и массив — это просто кусок памяти с произвольным доступом
Нет, массив — это упорядоченный в памяти кусок данных у которых есть указатель на первый элемент (а каждый последующий берётся за константное время через сдвиг адреса).
Вопрос был про то, что в PHP массивов нет. Мой ответ был про то, что в PHP массивы есть (строки), потому что они хранятся в памяти как упорядоченный и неразрывный кусок памяти. И доступ к элементам этого массива всегда константный, даже на уровне кода ядра PHP.
Потому что в PHP нет никаких "utf-8 строк", о чём я в самом начале и написал.
А там где есть такое, вполне возможно выровненное хранение, где на 1 буковку приходится строго 4 байта (например utf8mb4 в maria/mysql) добитые нулями (но это, кстати, тоже не точно, нужно сырцы БД потрошить). Потому что кейс с вариативным размером — это уже практическая задача с декодированием и должна была звучать как "За какую алгоритмическую сложность можно декодировать utf-8" и в этом случае уже проще почитать всякие статьи: https://habr.com/ru/articles/138173/
Но ты прав в том, что вопрос ушёл вообще в другую сторону, а я повёлся)))
Думаю это дело привычки. Ориентироваться в иерархии в любом случае в варианте от SCSS попроще будет.
Что в свою очередь разворачивается в:
Контекст моей "претензии" был в сторону того, что статья позиционируется как "используем генераторы", но ни слова про то, что основная задача генераторов - это ставить выполнение функции на паузу для переключения контекста исполнения на выполнение других процессов.
А не то, что "инструмент выбран не правильно" ;)
Да, он экономит память, но это лишь побочный эффект того, что в коде не используются массивы в которых хранятся все данные выборки.
P.S. Оригинальная реализация с `while($cursor->getNext()) {}` работает ровно по такому же принципу - не создаёт массив, а каждый раз возвращает новые данные. Вот альтернативный пример как это можно делать, экономя память, вместо генераторов.
Небольшое примечание/замечание: Вообще это довольно популярное заблуждение, что
yieldпридуман для того, чтобы экономить память. С таким же успехом можно взять обычныйIteratorи в результате можем получить потребление ещё ниже, нежели в случае с генератором + выше производительность.И хоть использование этого оператора, очевидно, удобнее, нежели писать итератор руками (или лучше просто взять готовые реализации коллекций с поддержкой функции
map), однако он в первую очередь направлен на реализацию кооперативной многозадачности, которая в современно мире уходит в сторону файберов.Поэтому, считаю, тема
сисегенераторов раскрыта не до конца)Так на 11ой винде, судя по скринам, при развороте на полный экран окна — нет скругления и они квадратными становятся.
О, всё как просто! Выгляжу теперь как дурак :D
<spoiler>А вот про скругёлнные окна не надо! После скруглённых окон XP, после скруглённых окон Висты, после скруглённых окон семёрки (я уж не говорю про гном, кеды, циннамон и мой любимый буджи) приходит Win 10 и приносит с собой 2000ый год и франкиншеин‑дизайн 98ой винды, сделанный какими‑то криворукими... кхм...
В общем, Win11 с точки зрения плавности, анимашек и интерфейса в целом — прям шикарная. Этакие кеды на минималках. У каждого свои вкусы, в общем.</spoiler>
P.S. К слову о дизайне и эффективных дизайнерах, ээээм... А как сделать спойлер с оффтопом в этом новом и безусловно супер-современном текстовом редакторе хабра?))) Всё перепробовал и перетыкал уже...
Да и если нужно веб-морду посмотреть, то всяко проще встроенный PHP сервер поднять, а не возиться с монструозным апачем.
С другой стороны bcrypt/blowfish уже считается относительно устаревшим (PHP 7.2+) в пользу актуального на данный момент argon.
Тащемта написать нативное (именно нативное, а не то что в статье) приложение на PHP с нативными вызовами winapi (или чего другого) будет попроще, нежели на тех же плюсах (например). Другое дело, что в PHP просто нет экосистемы, которая бы упрощала всё это дело (вроде Qt, XAML, JavaFX, etc.), а работать с лоу-левел вызовами функций ОС — это боль.
Она не поддерживает C/C++. Так что пописать одновременно, например, на PHP и на Си (т.к. PHP поддерживает из коробки вставки на Си) не получится. Как, например, и на Java + JNI.
Да, перечитал с этими пояснениями — вы правы.
Вы говорите о том, что адекватный код на PHP 5.x запустится и на PHP 8.x. А автор цитаты говорил о любой совместимости, включая обратную. Мол, не надо тащить фичи 8.х, т.к. всё тоже самое можно запилить и на 5ке, которая никак "не влияет на бизнес-логику" (с).
По крайней мере я так понял его комментарий.
В php 5.6 не было Throwable и было много утечек памяти в ядре (хотя вроде в 5.6 большинство как раз подлатали), следовательно надёжное websocket приложение (чат, например), реализовать практически невозможно. Ну или страдать и постоянно перезапускать его.
Или, например, задача по сложным (в т.ч. матричным) вычислениям — без компьютед-шейдеров и/или AVX через FFI в php 7.4 эффективно реализовать простыми силами не получится.
Да кучу примеров можно привести, где реализация чего-либо на "не модной" версии языка просто невозможна без дописывания этой версии языка до функционала более "модной")
Если, кстати, говорить про фреймворки/библиотеки, то не вижу у современных библиотек рендеринга (React, Vue, etc) ни одного преимущества для построения интерфейсов против древнего как говно мамонта Knockout. Последний и намного проще в работе и изучении (ровно 3 функции нужно изучить), и гибче, и требует меньше зависимостей. Нормальных компонентов и фич шаблонизатора разве что не хватает, как у того же Vue, но в остальном — сабжи на фоне Ko выглядят как набор костылей и велосипедов.
Ну и ещё Aurelia из этого списка можно выделить, как развитие идей Ko, хоть и местами избыточный и переусложнённый.
Жаль что помер =(
И в чём тогда претензии? Массивы выделяются одним куском, да. А в пыхе такой кусок выделяется только для строк. Что не так-то?
Это когда я говорил, что список — это один большой кусок? о_0
Блин, очепятался конечно же)
1) Зато есть двухсвязные из коробки.
2) Их можно реализовать и технически они в памяти будут располагаться также, как и на С. И все обращения будут идентичными.
Любой список как раз и выделяет память в случайных участках памяти, в отличие от массивов.
Array в PHP как раз и не является массивом, т.к. может выделить непоследовательный участок памяти, хотя в подавляющем большинстве случаев делает это последовательно:
ссылко на сырец: https://gist.github.com/SerafimArts/dcf64d3211831d1c02a403c104d97f19
Не вижу противоречий. Float — это 1 байт, т.е. вполне себе массив из одного float или одного int8, или одного char, или двух int4 (если мы будем использовать lo + hi, как это сделано в некоторых системных апи). А ещё это может быть структурой:
Или мы можем взять uint32 и это будет массив из 4х uint8:
Опять же, вопрос репрезентации и способа работы: Либо воспринимать как одно число, либо как массив из чисел.
А вот списки уже нет, т.к. там нет никакой гарантии упорядоченности и целостности памяти.
Для начала, ещё раз повторюсь, что в PHP нет никаких utf-8 строк. А функции на то и функции, что реализуют алгоритмы поиска, декодирования и прочих манипуляций с данными. Никто при этом не мешает хранить utf-8 строку в UCS формате и искать в ней символы за константное время, а потом обратно запаковывать. Так же как никто не мешает распаковывать в памяти RLE-сжатие, находить в нём за константное время нужный элемент, а потом опять сжимать. Это лишь вопрос реализации декодера, а не вопрос разыменования элемента из массива.
Нет, массив — это упорядоченный в памяти кусок данных у которых есть указатель на первый элемент (а каждый последующий берётся за константное время через сдвиг адреса).
Вопрос был про то, что в PHP массивов нет. Мой ответ был про то, что в PHP массивы есть (строки), потому что они хранятся в памяти как упорядоченный и неразрывный кусок памяти. И доступ к элементам этого массива всегда константный, даже на уровне кода ядра PHP.
Не надо, пожалуйста, сравнивать тёплое с мягким.
Потому что в PHP нет никаких "utf-8 строк", о чём я в самом начале и написал.
А там где есть такое, вполне возможно выровненное хранение, где на 1 буковку приходится строго 4 байта (например utf8mb4 в maria/mysql) добитые нулями (но это, кстати, тоже не точно, нужно сырцы БД потрошить). Потому что кейс с вариативным размером — это уже практическая задача с декодированием и должна была звучать как "За какую алгоритмическую сложность можно декодировать utf-8" и в этом случае уже проще почитать всякие статьи: https://habr.com/ru/articles/138173/
Но ты прав в том, что вопрос ушёл вообще в другую сторону, а я повёлся)))