Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 39

Большое спасибо, всё как всегда очень интересно и познавательно)


Кто что думает про atk4/data?

Всего голосов 1: ↑1 и ↓0+1
Мотивы автора вполне понятны. Другой вопрос в том насколько возможности этой ORM покрывают реальные кейсы и не проще ли писать SQL.
Комментарий пока не оценивали0

SQL обычно всегда писать проще. СЛожнее поддерживать :)

Всего голосов 3: ↑3 и ↓0+3
Кто что думает про atk4/data?

очередной велосипед который очень активно форсится его автором. Это не ORM, это не совсем DBAL (хотя ближе к этому)… очень мутная дока… слишком много фич для одного пакета… Что бы объективно понять что это и кому оно надо — надо слишком много времени разбираться. Может быть кто-то осилит. Лично мне это не нужно.

Всего голосов 5: ↑5 и ↓0+5

Я попробовал разобраться. Похоже на data provider-ы из Yii + гриды / списки.

Всего голосов 2: ↑2 и ↓0+2
Спасибо за интерес. Я автор atk4/data. Пока весь материал на английском (русский знаю только разговорно), но если есть интерес, могу написать что то по русски.
Всего голосов 3: ↑3 и ↓0+3
RFC: Scalar Pseudo-type, — по-моему, это уже лишнее, как и mixed.
Всего голосов 8: ↑7 и ↓1+6

Scalar да, а вот миксед наше все, для некоторых классов.

Всего голосов 3: ↑3 и ↓0+3
А чем хуже не добавлять никакую проверку типа в этот метод вместо mixed?
Всего голосов 3: ↑3 и ↓0+3
Консистентность и наглядность — это не «забыли указать тип», а «указали любой тип».

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

А вот скалярные да, не могу придумать ненатужный пример их использования.
Всего голосов 5: ↑5 и ↓0+5
Если в функцию может прийти null, 0, 0.0, «0» или false и она всё это приведёт к булевому значению, то это, конечно, гибко, но с кодом выше явно что-то не то.
Всего голосов 1: ↑1 и ↓0+1
Ну, например, нужна строка, которая куда-то выводится или записывается в файл, допустим. Числа спокойно в строку конвертнутся и выведутся, как надо. А вместо массива будет «Array».
Комментарий пока не оценивали0
Числа в строку — ок. Буль в строку — не ок. Для этого кейса правильнее указать «int|float|string» (но я не помню приняли ли это RFC).
Комментарий пока не оценивали0
Тогда нужно составные типы вводить, или какой-нибудь очередной псевдо-тип, или numeric тот же использовать. Видимо, чтобы не париться взяли существующие scalar, а на бул забили.

Хотя bool корректно конвертируется в строку и обратно, как и остальные скаляры, в отличии от массивов и остального.
Комментарий пока не оценивали0
Я о том и говорю — нужные составные типы, потому что они покрывают больше кейсов, чем scalar. И такой RFC уже был, но я не помню его судьбу.

Если примут scalar, но не примут составные типы — это будет очень странно.

В дополнение к составным типам ещё хорошо бы зашли алиасы для них — можно спокойно будет объявить свой scalar там, где он нужен и ещё много чего.
Комментарий пока не оценивали0
Сколько вы хотите от бедного PHP. Потом вам ещё подавай описание схемы ассоциативного массива :)
Всего голосов 1: ↑1 и ↓0+1
Я уже давно привожу в пример реестр, на данный ответ. В реестре может хранится как bool, так и string, так и array (при получении всей ветки). И что я должен выводить, кроме mixed?
Всего голосов 1: ↑1 и ↓0+1
Ничего, просто не делать проверку типов. Вы же таким образом никак не ограничиваете тип, который придет в метод.
Всего голосов 1: ↑1 и ↓0+1
Это уже похоже на какой-то «культ карго» и проверки ради проверок. Зачем указывать любой тип в сигнатуре функции в языке с динамической типизацией?
Комментарий пока не оценивали0
Не для того, чтобы его язык проверил, а для того, чтобы код был читаемым. Я выше уже привёл пример. Это просто часть стайлгайда — если указываем типы, то указываем везде, хотя бы для того, чтобы не возникало вопросов.
Тип — это документация. Если указан mixed, то сразу понятно что ожидать. А если ничего не указано, то нужно открыть реализацию и всю её прочитать, чтобы убедиться что да, mixed, а не просто кто-то забыл тип проставить. Можно, конечно, завести правило «не указан тип читай mixed», но зачем эта когнитивная нагрузка?
Всего голосов 6: ↑6 и ↓0+6
Спасибо за подробное объяснение, звучит разумно.
Всего голосов 1: ↑1 и ↓0+1
Ну да, по сути культ карго. Ровно в той-же степени как и ООП. Мне стало удобней использовать строгую типизацию и «бить разрабов по рукам» за то что они не понимают что к ним приходит и что от них требуется. На данный момент mixed тип висит аккурат пустым, я согласен, это удобно, но если мы говорим про попытку внести строгую типизацию — таких лазеек оставлять нельзя.
Всего голосов 1: ↑1 и ↓0+1
Понял, спасибо.
Комментарий пока не оценивали0
Я бы в место mixed предпочел иметь возможность перечислять несколько возможных возвращаемых типов, было бы и «строже» и читабельнее.
Всего голосов 5: ↑5 и ↓0+5
Согласен с вами на все сто. Не знаю что останавливает разработчиков php просто взять и скопировать бест практис PHPDoc, где уже давно есть param string|bool. Вот самая ожидаемая фишка была-б.
Надо предложить сию идею товарищу Попову, мб заинтересует.
Всего голосов 5: ↑5 и ↓0+5

Да ладно PHPDoc, свою же документацию хотя бы можно было бы скопировать для сигнатур.

Комментарий пока не оценивали0

С другой стороны, есть ситуации, когда прийти может реально любой тип и функция/метод готовы его обработать, например, dump() serialize() и т. п.

Всего голосов 1: ↑1 и ↓0+1

лучше б uniont/interseption типы запилили...

Всего голосов 3: ↑3 и ↓0+3
Вот мне тоже кажется, что от этого было бы больше пользы, чем от mixed/scalar. Вроде и разумные способы применения выше в комментариях были описаны, но все равно это какой-то костыль. uniont/interseption те же проблемы решили бы красивее и строже.
Комментарий пока не оценивали0

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


type Friends = iterable & Collection

Даже без union types и т.п. это уже позволяло бы повысить выразительность и не создавать так много контейнеров для данных, так же это бы горманично сочиталось бы с дженериками (которые хочет МорисонЛеви протолкнуть)

Всего голосов 4: ↑4 и ↓0+4
Да, это было бы весьма полезно.
Комментарий пока не оценивали0

По поводу amphp/parallel — оно реально раскидает по ядрам или будет на одном ядре делать?

Всего голосов 1: ↑1 и ↓0+1
Судя по описанию, по ядрам не раскидает, так как использует Amp. Amp, насколько вижу, реализует корутины с помощью генераторов, что зачастую позволяет значительно поднять производительность даже на одном ядре.
Комментарий пока не оценивали0
На винде пример из статьи раскидал на 3 воркера (отдельные 3 процесса) и 1 мастер. Возможно, если запустить к примеру на дебиане с каким-нибудь pthreads под php раскидает на потоки, к сожалению сложно проверить.
Комментарий пока не оценивали0

Раскидает. Но это всего лишь обертка proc_open на yield-ах.
На каждый ParallelTask будет создаваться отдельный php процесс

Всего голосов 1: ↑1 и ↓0+1
У amphp/parallel есть несколько драйверов для работы. Есть реализация на процессах и тредах. Для тредов нужен pthreads. Для процессов ничего не нужно.
Комментарий пока не оценивали0
Спасибо за подборку.
Всего голосов 1: ↑1 и ↓0+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr