После года разработки представлен релиз языка программирования PHP 8.3. Новая ветка включает серию новых возможностей, а также несколько изменений, нарушающих совместимость...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60172
Большинство слоупоков до сих пор сидят на 7.4.
> Большинство слоупоков до сих пор сидят на 7.4.а некоторые и на 5.x
потому что без конца переписывать уже написанный работающий код - дураков нет.
А авторы нескучного вебязычка пошли тем же путем что пихон - ни одной minor version без поломанной обратной совместимости и при этом отказ от поддержки всех предыдущих, патамушта у них лапки.
Когда строгие коллекции??
Для этого дженерики нужны. Можно, конечно, сделать только массивы, как в Golang, а потом страдать, но в пхп и так достаточно страданий
Вроде в HHVM есть дженерики, может и в PHP когда-нибудь завезут, если решать что они там нужны
> Для этого дженерики нужны.А еще указание variance. Ибо если делать как в Java, то получается нетипобезопасно, потому что массивы коварианты. Хорошо хоть в golang инварианты.
Так, например, след. код на javaclass Main {
public static void main(String[] args) {
String strings[] = {"house", "daisy"};
Object objects[] = strings; // covariantobjects[1] = "cauliflower"; // works fine
objects[0] = 5; // throws exception
}
}
>> Для этого дженерики нужны.
> А еще указание variance. Ибо если делать как в Java, то получается
> нетипобезопасно, потому что массивы коварианты. Хорошо хоть в golang инварианты.Также есть хорошее сравнение по variance в одном из последниз PEP питона https://peps.python.org/pep-0695/#summary
Решается через PHPDoc и добавления анализаторов кода типа psalm и phpstan
Не проще сразу другой язык выбрать?
не хочу быть банальным, но не могу удержаться от вопроса: ОНО ЕЩЁ ЖИВО?! лол
>ОНО ЕЩЁ ЖИВОоно небось всё ещё 50+ % веба занимает.
это если как измерять? по количеству посетителей? сомневаюсь, что гугл написан на пыхе.
Facebook/VK по-прежнему крутятся на нём.Лол оставьте дома.
оно нас переживет.
кто знает, а пы-хы-пы такой же безопасный как раст или как си дидов?
поставлю вопрос по другому, какой безопасный язык программирования использовать для веба?
> какой безопасный язык программирования использовать для вебаБудто у тебя есть выбор. Ответ на моей аватарке.
тут спрашивают про безопасный, а не про язык для смузихлёбов
Пых уязвимей ассемблера, если ты хотел об этом знать.
F#
На вебне эксплуатируют кривизну поделки или браузера и от языка сервера это мало зависит.
Вордпресс и битрикс на пыжике например, вспотеешь обижать, если(ага) правильно стоят.
За жабаскрипт или го? Да так же точно всё.А бебезопастность памяти? Так уборщик мусора есть.
Для веба нужно HTML.
Ещё немного (НЕМНОГО Я СКАЗАЛ!) css.
Html, css, Javascript а ещё уметь юзать графические редакторы, бек на php тож не лишним будет
Можно попробовать C (например, с фреймворком Wt). Но в любом случае безопасность упирается в WEB сервер.
Вопрос в другом, напишет какой-то Васян на безопасном языке, а его поезд собъёт. Владельцу бизнеса искать еще одного Васяна???
Так в России поездов больше, чем не криворуких модно-кодеров.
Бизнесу на твою моду как то наплевать. Бизнесу прибыль нужна!
> поставлю вопрос по другому, какой безопасный язык программирования использовать для веба?Поставлю вопрос иначе. Большинство приложений в мире сейчас сервируют веб. Так нахера его писать на жручих тормозных "безопасных" есыках, если даже на них обезьяна с гранатой всё равно напишет что-то опасное? Капиталисты убивают планету ставя печки для исполнения этого тормозного кода лишь бы не нанимать кодеров, способных писать безопасный код на "опасных" есыках!
А кто сказал, что раст безопасный?
какие-то маркетологи
Думаю пора этот язык не развивать. А рекомендовать переходить на другие ЯП.На Пайтон. Он куда более универсальный, хоть и похож
На модный go
Та даже на JSЖаль что до сих пор когда гуглишь какой первый ЯП учить натыкаешься на PHP
Думаю, сэр немного заблуждается. Так что не жаль.
Из динамически типизируемых скриптовых PHP по структуре как раз больше всего подходит для бэкенда. То есть, это такой баланс: когда проект достаточно здоровый, чтобы писать его на python, но и нет необходимости скорости, чтобы переходить на шарпы/джаву. В целом, свою нишу занимает. 8-ой не трогал, писал на 7-ом. За исключением пары исторических моментов, язык понравился.
Js в беке имхо тот ещё мазохизм. Тогда уж лучше Ts
Надо ввести жёсткую модерацию на попытки уместить в одном предложении слова "скорость" и "джава".
Или познакомиться с продуктами JetBrains, давно развенчавшими этот стереотип.
У вас ошибка, должно быть подтвердившими
Если только не видел PhpED.
Win-only IDE в 2023? Не видел и не увижу.
Речь не об ОС, а о быстродействии.
> Речь не об ОС, а о быстродействии.Если что-то летает, но только под Мак - мне от этого ни горячо, ни холодно.
И если вы подозреваете, что я за тридцать лет программирования ничего, кроме Шторма, не видел и поэтому хвалю JetBrains - боюсь, вы заблуждаетесь.
Я хорошо помню, как MSVS С++ летала в версии 2008 года и как она же стала диким тормозом в 2010, например. Хотя язык отнюдь не менялся... просто эти рyкoжoпы загнали анализ кода в свою монструозную БД. Никакие Кресты и Шарпы от этого, внезапно, не спасли.
Java-продукция JetBrains работала заметно медленнее версии PhpED, выпущенной в то же время. Это и понятно — managed-язык закономерно медленнее компилируемого.
> Это и понятно — managed-язык закономерно медленнее компилируемого.Если они выполняют одни и те же алгоритмы в сферическом вакууме.
Право, если вы хотите поразмахивать примитивными стереотипами - давайте без меня.
PhpED был быстрее не в теории, а на практике. В одно и то же время, в одной и той же ОС.
А Notepad++ был еще быстрее. Переходите уже на него и не делайте мне голову.
У ПО одного класса в одно и то же время обычно паритет по функциональности.
> У ПО одного класса в одно и то же время обычно паритет по функциональности.Я, наверное, мало знаю IT. Не могу припомнить ни одного примера, подтверждающего это заявление.
В сравнении с чем? С каким-нибудь python и думаю PHP быстрее
Нишу дохлого легаси занимает успешно, да. Кол-во вакансий не даст соврать.
И что мне должно сказать количество вакансий? То, что сейчас у каждой компании по 3-х страничному сайту? Это и без количества вакансий понятно. Компаний много, всем нужен интернет магаз на коленке собранный или лендинг какой-нибудь. Тут и заходят все эти python, node.js и PHP. Считай их ниша. Для чего-то по серьёзнее (что, понятно, нужно реже) берут C#, java. В совсем нагруженных случаях вообще C++. От сюда и получаем такую статистику по вакансиям, а вовсе не от того, что легаси
«Больше всего подходит для бэкенда» и переменные, мутирующие от того, что на них косо посмотрят, в одном предложении…
А в python или js всё ровно с этим? Особенно в js
Не то, чтоб я за пхп, но в чём преимущество питона в вебе?
Ну чем оно лучше? Нет, можно и питон, но чем он лучше?
Он быстрее пыха вот в чём.
Сомнительно, а с учетом того, что PHP где нужна скорость компилируется JIT, то и неверно.
Нет, не быстрее )
А вот тут по подробнее. Пхп с версии 7 вроди как нехило так ускорился, за счет использования jit компиляции и обошел по скорости питон, причем значительно. Не?
JIT в 8
Но тем не менее 7 нехило так ускорилась, в частности за счёт прекращения копирования части структур до момента, пока их не поменяют.
настолько быстрее что в разы медленнее
Учитывая, что на голом что Пыхе, что змеюке под веб никто почитай и не пишет - то сравнивать надо не "языки", а конкретные фреймворки умножая на коэффициент руко...крылости разработчиков и тут возможны разнообразные варианты. Впрочем, для большинства проектов голый пырформантц в первую тройку критериев для выбора не попадает.
Производительность веб-проекта - что на пыхе, что на питоне, да даже на жабоскрипте - в основном зависит от того, насколько хорошо разработчик знает... SQL.
> Производительность веб-проекта - что на пыхе, что на питоне, да даже на
> жабоскрипте - в основном зависит от того, насколько хорошо разработчик знает...
> SQL.Вообще да, но нет ). Или вернее, от того, насколько хорошо SQL знает разработчик ORM\framework'а - поскольку в большинстве случаев будет примерно дефолт :).
> насколько хорошо SQL знает разработчик ORM\frameworkЭти ребята обычно все-таки разбираются, и проблемы с конечным разработчиком.
Например, запрос можно сформировать с пагинацией, а можно без. На тестовых объемах разница незаметна, а вот через несколько лет работы полумиллионная таблица, которую чисто для вывода первых 20 записей запрашивают целиком... ну, не будем о Битриксе ;)
вы про что? limit 20 нет в запросе? логика там какая - чтобы без доп запроса показать всё по требованию? where пользоваться под нужный диапазон тоже не научились?)
> вы про что?
#bitrix/modules/sale/admin/transact_admin.php
-$dbTransactList = CSaleUserTransact::GetList(array($by => $order), $arFilter, false, false, array("*"));
+$dbTransactList = CSaleUserTransact::GetList(array($by => $order), $arFilter, false, array("nPageSize" => CAdminUiResult::GetNavSize($sTableID)), array("*"));
Вообще-то нет. CRUD какой-нибудь сильно на производительность не влияет, а сложные запросы всё равно приходится писать на SQL, просто оборачивая результаты их работы в объекты ORM. Так что действительно тут больше зависит от знания SQL и оптимизации базы данных.Часть логики, если она сильно влияет на производительность, пишется модулями на C, и тогда в целом тоже всё равно - это модуль для PHP или для Питона. Мы так писали например функции для работы с географическими данными, типа рассчёта расстояния между точками на карте с учётом кривизны планеты, быструю выборку из нескольких близких точек и т.п.
Хм. У нас на последнее postgis воткнут - в общем-то хватает, впрочем задач крупнее городской теплосети пожалуй что и нет.
> голый пырформантц в первую тройку критериев для выбора не попадаетЭто временно. Пока начальство не вызвало и не попросило объяснить счета за хостинг и/или почему всё так тормозит.
>> голый пырформантц в первую тройку критериев для выбора не попадает
> Это временно. Пока начальство не вызвало и не попросило объяснить счета за
> хостинг и/или почему всё так тормозит.АБСОЛЮТНОЕ большинство веб-проектов до этого светлого момента просто никогда естественным образом не дорастает, вот в чем фокус.
Да и фиг с ними. Главное, что кодер на модном язычке получит свой гонорар и свалит в следующий стартап.
> Да и фиг с ними. Главное, что кодер на модном язычке получит
> свой гонорар и свалит в следующий стартап.Клиент получает требуемую функциональность, разработчик - гонорар, win-win практически. А то, что через три года у клиента _могут_ возникнуть проблемы с производительностью... ну в общем "клиент типовой, резиновый" не готов ждать на полгода дольше и платить в три раза больше, чтобы _возможно_ не иметь проблем в будущем. Как-то так оно в реальном мире устроено.
Ну вообще в реальном мире бизнес борется за живучесть и задаётся вопросами техподдержки. Кто не задаётся такими вопросами со временем всё равно отомрёт, даже если приложение спроектировано грамотно.
> Ну вообще в реальном мире бизнес борется за живучесть и задаётся вопросами
> техподдержки. Кто не задаётся такими вопросами со временем всё равно отомрёт,
> даже если приложение спроектировано грамотно.Ну в общем да. Стоимость поддержки решения в критериях выбора - есть. Тыр-пыр-формантца (Который, заметим, с этой "стоимостью" некоторым образом в контрах) - нет. Нет, если говрить о чисто IT'шных бизнесах - то тут возможны варианты, и то не факт - мордокнига смотрит на вас с определенным недоумением.
Клиент планирует посещаемость своих сервисов и сейчас, и через год, и через три года, и если он не прописал в договоре требования к производительности и масштабируемости, и не определил методику тестирования, а просто ограничился проверкой сервиса со своего клиентского устройства, принял и оплатил работу, а при мало-мальской нагрузке сервис лёг - ну, не повезло, связался с мошенником, а мозгов разоблачить его на хватило.
> Клиент планирует посещаемость своих сервисов и сейчас, и через год, и через
> три года, и если он не прописал в договоре требования к
> производительности и масштабируемости, и не определил методику тестирования, а просто
> ограничился проверкой сервиса со своего клиентского устройства, принял и оплатил работу,
> а при мало-мальской нагрузке сервис лёг - ну, не повезло, связался
> с мошенником, а мозгов разоблачить его на хватило.Айтишники-такие-айтишники. За первые два года закрывается больше половины бизнесов в России - но инструмент для создания сайт-визитки надо выбирать исходя из требований к производительности и масштабируемости. Да. Такъ победiмъ!
Однодневки-прачечные, как правило, обходятся без сайтов, даже одностраничных визиток. Для прочих видов бизнеса желательно умение смотреть чуть дальше собственного носа.
Ну, надеюсь что "про it" вы знаете хоть чуть-чуть больше, чем "про бизнес", да.
Вы своё знание и того, и другого продемонстрировали. Так что да, надежда - это всё, что Вам остаётся.
Если учитывать что писать на нескольких языках такое себе.. типа прыгать с одного на другой так себе удовольствие..На пайтоне можно писать скрипты, программы для десктопа. машинное обучение, нейронные сети, ну и бекенд..
На пхп только бекенд. Если нет у вас в планах писать всю жизнь бекенд, мне кажется вы освоете новый ЯП который вам понравится больше не для бека, для других целей, но начнете писать на нем так же и бекед) Хех)
Там на гошке, либо еще на чем-то
> Думаю пора этот язык не развивать.Обоснуй, а то звучишь так авторитетно, прям так и хочется поверить
> На Пайтон. Он куда более универсальный, хоть и похож
Ты по скорости не пробовал его с сабжем сравнивать?
> На модный go
Го - значительно больше низкоуровневый, не всегда это надо
> Та даже на JS
Сорри, но жoпy с пальцем сравнивать, JS - асинхронный, управляемый событиями, когда PHP - синхронный.
> Жаль что до сих пор когда гуглишь какой первый ЯП учить натыкаешься на PHP
Use the right tool for a job
Юзай Swoole, ежели асинхронщину желаешь.
Ну, у меня допустим ныне свой стек короутин для PHP. Линейный (в отличие от реакта, который заставляет строить ужасающие своим размахом деревья), очень коротенький (тысячи 2 строк на всё про всё включая сахар), простой и пристойный. Будет время - выложу в паблик, хотя смузям не зайдёт.
И да, с не***ческим перформансом - ~10000000/s переключений задач на 3.4GHz ядре, если задачи на генераторах. Это всего ничего - ~350 тактов на переключение. Если на файберах - в ~1.6-1.8 раза больше тактов, меньше задач.
>рекомендовать переходить на другие ЯП.На Пайтон. Он куда более универсальный, хоть и похож
А какая универсальность яп тебе нужна для веба? Сайты должны загружать страницы и все. Как бы я не любил php, но с этим он отлично справляется, собственно для этого его и создавали.
php после 4й версии закончился
Сейчас мы наблюдаем какую-то химеру
Его бы немного почистить от лишнего, создается впечатление что уж больно много всего в языке. Создается впечатление что внем функции под каждый чих...(утрированно)
> создается впечатление что уж больно много всего в языке.Классический вариант, когда подхватывается корпоративно
> Создается впечатление что внем функции под каждый чих...(утрированно)
С одной стороны, да - смешно, но с другой, вы посмотрите на оптимизации для каждого чиха, которые позволяют уделывать другие подобные языки по скорости
И вот в этом его прелесть. Для простейшей задачи не надо тащить 100500 зависимостей из разных npshit'ов.
> в нем функции под каждый чихЭто пугает только новичков, которые в панике представляют, что это все надо вызубрить.
На самом деле, это как раз приятная особенность пыха: в его стандартной библиотеке куча оптимального кода на С, которым можно воспользоваться, как только тебе понадобилась эта оптимальность - вызвав одну из этих многочисленных функций (собственно, просто оберток над вызовом библиотечной функции).
Например, недавно при обсуждении одного довольно ресурсоемкого алгоритма, реализованного на чистом пыхе, мне подсказали функцию, о существовании которой я и не подозревал, хотя давно пишу на РНР. С минимальными изменениями алгоритма замена одного из его блоков на эту функцию ускорила его в 25 раз!
Озвучьте функцию все равно аноним
А смысл? Это не какая-то серебряная пуля, которая сделает любому быстрее и лучше.
Это оптимальная реализация конкретного алгоритма, который мне подходил по логике.
В пыхе нынешнем конечно есть свои idiosyncrazy с производительностью, если надо в качестве ЯОН.Например вот этот вот сахар вокруг статических типов - прилично увеличивает стоимость вызова. Лишняя проверка при каждом вызове.
Вызов функции или метода - очень дорогой. На критичных участках кода, выполняющихся десятки тысяч и более раз - лучше избегать в пользу развёртывания. Эдакий лютый привет любителям овердекомпозиции :) Инлайна в динамическом языке нет, естественно. Причём не только своих методов, вызовы рантайма тоже очень дорогие.
switch с case $this::const или class::const менее производителен, чем switch с case "string". Если аргумент switch - строка и более-менее постоянен (внутренний хеш формируется для каждой строки 1 раз), например редко меняемая property - вместо констант класса в критичных участках кода в switch лучше использовать строки напрямую.
И т.п.
> На Пайтон. Он куда более универсальный, хоть и похожПару букв схожи? Рукалицо
Почему униварсальность значит лучше?>На модный go
Го немного про другое. Хотя и на нем есть веб, но все таки он про другое
>Та даже на JS
А где он выполняется, ты знаешь? А где РНР? Разницу объяснять?
>Жаль что до сих пор когда гуглишь какой первый ЯП учить натыкаешься на PHP
Жаль что есть такие люди как ты, которые крестовой отверткой гвозди забивают и кричат что микроскоп с этим справится лучше.
РНР не зря лучший веб язык для написания ВЕБа разного уровня.
Работает быстро. Работает прозрачно. Обучение дешевое и быстрое. Универсальный.
Пыхтон - обречённый язык из за dependency hell.
Он ещё кое как работает обмазанный venv и докерами, но всё больше скатывается к состоянию: "работает только на машине разработчика".
Учитывая то что там часть пакетов - биндинги которым нужны либы из системы, то оно не поддерживаемое для больших проектов.JS - там проще, всё написано на самом JS, это сразу на порядок меньше головняков у тех кто это использует и обслуживает.
GO - всё нужное опять же носит с собой.
PHP - тоже без внешних зависимостей, есть некоторое фиксированное количество компонентов которые собираются в системе, остальное реализуют самим языком.
Язык-то красивый сам по себе, только тормоз. Питон тоже тормоз. JS тоже тормоз. Go - ну если не загружать его по новой на каждый запрос, будет быстрее. Но он тоже "безопасный", то бишь обработка строк, из которых чуть более чем полностью состоит веб, будет в разы дороже "опасных" языков. Тормоза - это не только user experience, это ещё затраты на более мощное железо, на электричество для этого железа в датацентрах, на электричество для кондиционеров для отвода тепла выработанного железом в датацентрах в атмосферу нашей планетки. Т.н. "безопасные" языки программирования опасны для человечества.
На современном веб-сайте обычно работают три языка-посредника.
JS на фронте - между пользователем и веб-сервером.
РНР на бэке - между веб-сервером и сервером БД.
и SQL в БД - между тем, что понадобилось сайту, и реальностью его хранения.
Вот последний бывает критичен по производительности, а чаще - по умению на нем писать.
Два других же, как правило, не играют в скорости работы сайта решительно никакой роли, если писал на них не совсем уж жoпopук.
> JS на фронте - между пользователем и веб-сервером.От всей души желаю _некоторым_ разработчикам _некоторых_ сайтов пользоваться RaspberryPi для их просмотра. Иногда страница пару минут грузится. Это говорит от том, сколько бесполезной нагрузки (в т.ч. для экологии) они несут.
> На современном веб-сайте обычно..
> РНР на бэке - между веб-сервером и сервером БД.Думаю, что похапе - это не обычно. Если считать не по количеству сайтов, а по количеству запросов.
> и SQL в БД - между тем, что понадобилось сайту, и реальностью его хранения.
Вот да, и никакого кеширования между похапэ и БД.
> Вот последний бывает критичен по производительности, а чаще - по умению на нем писать.
Естественно заход в базу дорого обходится. Но _обычно_ данные кешируются. Не у васянов, конечно. Следующий уровень сложности - обеспечение транзакционной целостности не только в БД, но и в кеше. Чот не видел в опенсорце :)
Нынешние малинки несут на себе четыре ядра и восемь гигов памяти. Уделывая значительное число офисных машинок ;)
Именно такой я и пользуюсь. Некоторые сайты тормозят нещадно.
Ну, там скорее не кривые скрипты, а визуальные вытребеньки типа параллаксов и видеоподложек.
Есть в этом мире вещи настолько кривые, что выпрямить их можно только единственным способом...
Тормоз в PHP начинается тогда, когда идёт совершеннейшее непонимание принципов его работы.
Овердекомпозиция с методом на каждые 10 строк - одно из таковых. Вызов метода в PHP - удовольствие ОЧЕНЬ дорогое.
> Тормоз в PHP начинается тогда, когда идёт совершеннейшее непонимание принципов его работы.
> Овердекомпозиция с методом на каждые 10 строк - одно из таковых. Вызов
> метода в PHP - удовольствие ОЧЕНЬ дорогое.Разрабочиков Nextcloud сложно заподозрить в совершенном непонимании пыха, однако как же он тормозит!
Вы внутрь Nextcloud заглядывали?
Тут не то, что заподозрить, тут как раз таки всё "на лице".
Так можно писать исключительно на компилируемом языке.
> Вы внутрь Nextcloud заглядывали?
> Тут не то, что заподозрить, тут как раз таки всё "на лице".
> Так можно писать исключительно на компилируемом языке.Если такое можно писать только на компилируемом языке, то авторы как бэ ни при чем. Виновны только в выборе негодной платформы.
И я о том же. Выбирают PHP, а пишут как на жабах.
> И я о том же. Выбирают PHP, а пишут как на жабах.Тут не понял. Насколько я знаю, в пыхе Zend-оптимизатор компилирует текст программы и потом уже исполняет байткод, т.е. практически как в джава. С чего бы ему быть медленнее?
Так, да не совсем. В жабе типы и структуры анализируются предварительно, и собранный байт-код работает с фиксированными знаниями о том, что прилетит в тот же вызов, с фиксированными структурами, определяющими, какие у класса есть свойства и каких типов, и т.п. Большая часть сборки осуществляется один раз на этапе трансляции в байт-код. У PHP же вся сборка - динамическая, каждый загружаемый файл, каждый создаваемый класс - всё это парсится и транслируется в рантайме. Да, кешируется в opcache, но всё равно часть трансляции есть даже при взятии из opcache.
> Так, да не совсем. В жабе типы и структуры анализируются предварительно, и
> собранный байт-код работает с фиксированными знаниями о том, что прилетит в
> тот же вызов, с фиксированными структурами, определяющими, какие у класса есть
> свойства и каких типов, и т.п. Большая часть сборки осуществляется один
> раз на этапе трансляции в байт-код. У PHP же вся сборка
> - динамическая, каждый загружаемый файл, каждый создаваемый класс - всё это
> парсится и транслируется в рантайме. Да, кешируется в opcache, но всё
> равно часть трансляции есть даже при взятии из opcache.Мне даже такие детали не важны. Важен сам факт, что пых тормознее даже джавы. Дело не только в латентностях. Тупо в ненужных вычислениях, на которые тратится электричество и кремний.
Строчить и строчить однотипные комменты в вебе.
Хватить тратить такты и кремний! Кончай издеваться над природой!
И не "такое", а "так", не путайте.
Попытка перенести подходы с компилируемых языков на динамический обречены быть унылым тормозом.
> И не "такое", а "так", не путайте.
> Попытка перенести подходы с компилируемых языков на динамический обречены быть унылым тормозом.Да, пардон, пропустил логическую связку. Можно писать и без вызовов функций вообще. Может и быстрее работать будет быстрее, но потом запутаешься в этой простыне кода. Получается, что для более-менее сложных проектов пых непригоден.
Но он и для простых проектов непригоден - не всё ли равно на чем навалять простенький код? Совершенно необязательно это должен быть похапэ. Зачем интерпретировать байткоды на каждый запрос, когда можно сконпелять во время разработки?
Если вкратце - то да, при овердекомпозиции пых - плохой выбор.
>> // Было array (-5 => 'a', 0 => 'b') // Стало array (-5 => 'a', -4 => 'b')ухх, а если пихнуть -0?
Imho -0 equ 0
В математическом смысле нет. Да и в программировании с плавающей точкой тоже.
-0 в пхп нет кажись (
"динамическая типизация" жеж
Он "-0" возьмет как аргумент "знаковое целое" по синтаксису и приведёт к "индекс массива", "-" в процессе отпадётА жаль)
В чем смысл пихания -0, если можно пихнуть просто 0? Я имею в виду - практический смысл, а не трансцендентные фантазии иррационалистов от разработки.
> В чем смысл пихания -0, если можно пихнуть просто 0? Я имею
> в виду - практический смысл, а не трансцендентные фантазии иррационалистов от
> разработки.я его явно не пихаю, он у меня может быть результатом вычисления индекса, к примеру (x / y) где x = 0, а y = -5, а в пхп как выше указали, -0 === 0
https://ru.wikipedia.org/wiki/%E2%88%920_(�...)
> он у меня может быть результатом вычисленияСовременные CPU не сбрасывают автоматически бит SF, если в результате целочисленной операции все разряды результата сброшены?
Господи, помилуй нас, грешных...
> Современные CPU не сбрасывают автоматически бит SF, если в результате целочисленной операции
> все разряды результата сброшены?
> Господи, помилуй нас, грешных...https://en.wikipedia.org/wiki/Negative_flag
операции умножения и деления не трогают этот флаг, там по две инструкции на каждую операцию.
https://pdos.csail.mit.edu/6.828/2012/readings/i386.pdf
страница 419-420
У IPU SF - это просто копия старшего бита результата, поэтому про -0 можно забыть.
В FPU ситуация немножко иная.
Посколько в данном случае индексы у PHP приводятся к строке через целые числа - про -0 можете забыть.
$ php -r 'echo 0 / -100, "\n";'
0$ php -r 'echo 0 === -0 ? "true" : "false", "\n";'
trueУ меня какой-то другой пхп стоит?
-0 нет в пхп
Интересно, кто-то вообще этим как-то пользовался?
В смысле задефайнить номер первого элемента, но не остальные.
Это ж прямой путь налететь на грабли.
> Интересно, кто-то вообще этим как-то пользовался?
> В смысле задефайнить номер первого элемента, но не остальные.
> Это ж прямой путь налететь на грабли.индекс первого элемента - 0 (в обычном понимании плоского "сишного" массива), -0 по сути должен был быть индексом последнего элемента, а в пхп нет понятия плоского "сишного" массива, там ключ-значение. Индексы "нумерического массива" даже в пхп это ключ-значение.
В PHP все массивы - ассоциативные, то есть хеши, да.
Чот он каким-то монстром стал, давно на нём не писал ничего.
Да, старые версии на 98 винде работают и поддерживают Utf-8. Если не гоняться за дизайном, можно PHP сайты с IE5 подружить.
Зачем ты утрируешь? 😠😡
пхп сайты можно даже с lynx и wap подружить.
Только непонятно при чем тут ЯП воще :)
Это же php с классами, а значит php++. Странно что js с классами тоже не назвали js++.
Есть (был, выкуплен) Objective-J.
О! Вопрос. А вот язык Юля(Julia), что думает о вэбе?
Слышал что ей восхищались, вот интересно стало...
Юля больше не вставляет.
Mojo?
This
Только Julia в отличии от Mojo существует в реальности.
> Разрешено создание замыканий из методов и передачи именованных аргументов в эти замыкания.господи какой трэш и ужас щас начнется
> OverrideДля Эллочки-людоедочки со словарным запасом в 30 слов.
> генерация отдельных исключений (...) в случае проблем, возникающих в операциях работы с датами и временем
> генерация исключения при попытке передачи объектов, ресурсов или массивов в переменных, определяющих границы диапазонаЭто же не по пхп-шному! Тру-пхп-вэй - это молча интерпретировать полученную переменную хоть как-нибудь, выдать хоть какое-нибудь значение, непредсказуемое, не укладывающееся ни в какую человеческую логику, но выдать и работать с ней дальше.
Учитывая что мой код состоит процентов на 15 из обработки ошибок, могу сказать, что проблемы были, но не столь существенные. Зато выброс исключений где не надо прилично увеличит объём этого кода бесполезными зажимами try { ... } catch (\Exception $e) { }, просто чтобы оно не проваливалось по стеку. Потому что кроме исключения можно получить например false.
А делать из PHP жабу, где все эти цепочки исключений отрабатываются фиг знает где, и в итоге всё равно осыпаются тут и там - я вообще не знаю, чем поколение смузи думает. Нормальная C-подобная отработка ошибок: получил false или другой код ошибки - отработал.
(и только если не хочешь отрабатывать на месте - вот тогда бросил исключение. САМ)
Ну вот #[Override] - это извращение.
Почему бы просто override не добавить.
Типа public override function xyzzy().
Куда-то оно не туда после 8.1 сворачивать начало совсем...
Анонимные классы - это тоже какой-то 3.14дец. Зачем??? Вся суть определений классов в их статичности.
Зачем вообще в вебе классы, когда задача в 90 % случаев просто сделать запрос к базе и вернуть результат.
> Зачем вообще в вебе классы, когда задача в 90 % случаев просто
> сделать запрос к базе и вернуть результат.С классами логика прогаммы организуется лучше, появляется новый уровень строгой типизации, который не даст тебе сделать лишних ошибок.. Я думаю это плюс для любого языка программирования.
ага, тенденция микросервисов и классов :))
это вид сарказма такой? а типовые взаимодействия с бд, что и является основой, каждый раз вручную что-ли кодить? в них же все обработки/чеки и по типизации, кста. автолоадером легко подхватывается и прекрасно работает. помимо них, ещё куча, которая с массивами работает, вычисления проводит и передаёт их предыдущим. нууу... 2/3 процедурных простыней в моём проекте, примерно, скрыто так. чяднт?
Не, я понимаю, что это очередная попытка решить проблему отсутствия множественного наследования - теперь можно на ходу лепить ***ту из классов, но лучше бы первое сделали.
> Не, я понимаю, что это очередная попытка решить проблему отсутствия множественного наследования
> - теперь можно на ходу лепить ***ту из классов, но лучше
> бы первое сделали.Множественное наследование - это извращение. Сам унаследуй и от папы и от мамы - тогда поймешь по реакции окружающих :) Интерфейсы рулят, и, судя по статье, они в пыхе есть.
Сразу видно дальше хеллоуврота или сборки из всяких pypinpm'ов не писавших...
ассоциация не решает проблемы?
А того, чего не хватает - так и нет.
А не хватает
- Множественного наследования (уже упомянул)
- Перегрузки базовых операторов
- Перегрузки методов (варианты наборов аргументов), ну и заодно к ним сахарка темплейтов под типы, последнее для тех, кто очень любит типизацию и смузи
иди со своими перегрузками и множественным наследованием сам знаешь куда
> А не хватаетПришел в Пых из Крестов, где этого есть. Но и там не пользовался, и здесь не вижу необходимости.
Множественное наследование - признак неудачной архитектуры ООП. Интерфейсы в РНР есть.
Перегрузки и прочий синтаксический сахар не решает никаких реальных проблем, только затрудняет чтение кода.
Вот более жесткой типизации, конечно, не хватает. Но тут бытие определяет - пых постоянно работает с внешними данными, которые, как правило - строки. Все равно приводить и валидировать самому.
> Пришел в Пых из КрестовА чего сразу не в Бейсик?
Опять он здесь. Пропал тред.
> и там не пользовался, и здесь не вижу необходимостиРечь не мальчика, но мужа. Респект.
> Вот более жесткой типизации, конечно, не хватает. Но тут бытие определяет -
> пых постоянно работает с внешними данными, которые, как правило - строки.
> Все равно приводить и валидировать самому.Вот в классе и валидировать - подходят ему эти данные или нет
+правда, чеки/конвертеры стоит иногда в отдельные классы выделять, чтобы массив, одними, правильно собрать с инпута и отдать другим на передачу в бд. в хеллоувордах всё это не проблема, конечно же))
Наследование реализации — корень всех зол.
Да и не надо его, когда есть интерфейсы классов и подмешивание через "include".
Подмешивание через include - это пять.
...
Я даже не знаю.
Похоже не только пых свернул куда-то не туда. Шею.
какие разработчики, такие и технологии.
да композицией, агрегацией это всё решается внутри, не надо ничего подмешивать. классы с неймспейсами легко же тянутся
Архитектурно есть у тебя сокеты например.У разных сокетов например (ну, сокетная асинхронная либа у меня) - разные варианты реализации. Есть потоковые, где можно фигачить любыми блоками и доступно чтение любого размера. Есть датаграммы, где надо читать датаграмму целиком. У типичного датаграммного UDP ещё и адрес надо читать. У TCP есть OOB. Есть псевдосокеты сообщений, которые аналогичны датаграммам, но может быть адрес и ID сообщения. И т.п. У разных сокетов есть разные эвенты, которые они пуляют слушателям при событиях.
Сейчас приходится всё это счастье подмешивать через превращение опций в interfaces + traits и цепочке наследования через прототипы, но это такие жёсткие костыли, что блин хочется всё это взять и вырезать. Множественное наследование решило бы проблему полностью, но нет, приходится костылить.
Как пример жёсткого костылингаclass PollingSocketPrototype implements \ATL\ITask { use \ATL\TTask; } # bring in Task class first as first level parent
class PollingSocketPrototype2 extends \ATL\Socket\PollingSocketPrototype implements \ATL\ISocket { use \ATL\TSocket; } # bring in base Socket class as second level parent
abstract class PollingSocket extends \ATL\Socket\PollingSocketPrototype2 implements \ATL\Socket\IPollingSocket { use \ATL\Socket\TPollingSocket; }
abstract class StreamBasePrototype extends \ATL\Socket\PollingSocket implements \ATL\Socket\Capabilities\IBulk { use \ATL\Socket\Capabilities\TBulk; }abstract class StreamBase extends \ATL\Socket\StreamBasePrototype
{
...
}abstract class StreamPrototype extends \ATL\Socket\StreamBase implements \ATL\Socket\Capabilities\IReadBytes, \ATL\Socket\Capabilities\IDelimitedReads
{
use \ATL\Socket\Capabilities\TReadBytes; # bring in readBytes capability
use \ATL\Socket\Capabilities\TDelimitedReads; # bring in delimited reads capability
}class Stream extends \ATL\Socket\StreamPrototype
{
...
}Всё вот это вот решилось бы множественным наследованием легко и просто.
Я понимаю, что ты в линейной вебне, которая в основном банальная модель и шаблонизатор - вряд ли это встретишь, но PHP уже давно вышел за рамки вебни, и поэтому вместо вот этого всего странного #[Override] сахарка хотелось бы чего-то серьёзного :)
Открой для себя композицию, делегирование и стратегии. Помогает от этой вот лажи, что ты пишешь, и множественного наследования избавиться.
Попей смузи, и расслабься.
Когда нечем композировать - композировать нечем. Такие дела.
Ну и да, множественное наследование - это как раз часть композиции-агрегации, которой нет, и это печально.
Причём реализовать-то уже просто - эмуляция выше легко бы могла быть сделана через use Class хотя бы, не Trait, а класс, который затягивает все интерфейсы и прочее содержимое эквивалентно Trait. Но нет, приходится костылять.
class Stream
{
inherit \ATL\Task; # ATL socket is a task
inherit \ATL\Socket\PollingSocket; # we are a polling socket
inherit \ATL\Socket\StreamBase; # use PHP Stream socket base
inherit \ATL\Socket\Capabilities\ReadBytes; # support readBytes
inherit \ATL\Socket\Capabilities\DelimitedReads; # support delimited reads
}Специально написал inherit вместо use - как бы это могло быть. Красивенько, да, по сравнению с костылями выше?
А решить это заменой наследования композицией - точно не вариант?
Начиная с socket is not a task but task has a socket.
Никак там не решишь, у разных типов сокетов разные включения, они могут частично перекрываться.
Часть включений перекрывает некоторые единичные методы родителей, но прекрасно использует все остальные.С таском тоже не выйдет - таск не обязательно сокет, это асинхронный таск вообще для всего. Корутина и её минималистичная обвязка, которая даёт возможности не задумываться о том, как оно вообще всё работает асинхронно, передаёт аргументы и получает результаты, и т.п. + управление, обработка эксепшнов по стеку тасков и т.д. и т.п.
Just for fun покажу минимальный тест сокета.class Test extends \ATL\Task
{
public function main()
{
Log::msg("Main task started");
yield true;try {
Log::msg("Creating socket");
$this->taskAddChildTask($socket = new \ATL\Socket\TCP('192.168.77.10', 80, 15));
yield true;Log::msg("Waiting for socket to connect");
if (($result = yield ($wait = new \ATL\Socket\WaitForConnect($socket))) !== true) {
if (is_array($result)) throw new \Exception("Socket error {$result[0]} while connecting: {$result[1]}");
throw new \Exception("Socket timed out while connecting");
}
Log::msg("Socket connected");
Log::msg("Local name: ".$socket->socketLocalName);
Log::msg("Remote name: ".$socket->socketRemoteName);Log::msg("Writing HTTP request to the socket");
$socket->writeBulk([
"GET /test.php HTTP/1.1\r\n",
"Host: alex-at.net\r\n",
"Connection: close\r\n",
"\r\n",
]);Log::msg("Waiting for write data to be flushed down");
if (($result = yield ($wait = new \ATL\Socket\WaitForWriteFlush($socket, 5))) !== true) {
if (is_array($result)) throw new \Exception("Socket error {$result[0]} while writing: {$result[1]}");
throw new \Exception("Socket timed out while waiting for write");
}Log::msg("Reading from socket");
$wait = new \ATL\Socket\Read($socket, 5);
$fout = fopen(__DIR__.'/socket_test.out', 'wb');
do {
if (($result = yield $wait) !== true) {
if (is_array($result)) throw new \Exception("Socket error {$result[0]} while reading: {$result[1]}");
throw new \Exception("Socket timed out while reading data");
}
if ($wait->readData !== null)
fwrite($fout, implode('', $wait->readData));
} while ($wait->readData !== null);
fclose($fout);Log::msg("Waiting for socket to disconnect");
if (($result = yield ($wait = new \ATL\Socket\Disconnect($socket, 5, true))) !== true) {
if (is_array($result)) throw new \Exception("Socket error {$result[0]} while disconnecting: {$result[1]}");
throw new \Exception("Socket timed out while waiting for disconnect");
}
} catch (\Exception $e) {
Log::msg("ERROR: ".$e->getMessage());
}if (!$socket->isDisconnected()) {
Log::msg("Aborting socket");
$socket->abort();
yield true;
}Log::msg("Main task ended");
}
}
Не знаком с используемой библиотекой, но в приведенном коде таски с сокетами смешиваются только в одной строчке. В которой точно так же можно использовать дочерний класс таска с членом-сокетом.
И не гневать святую Барбару..
В конкретной реализации - не можно.
Данный сокет, повторюсь, живёт своей жизнью, и к конкретному таску, кроме своего - не прибит.
Ещё есть сокеты-ендпоинты, которые вообще не таски.
И да, член у сокета есть, но ему кроме него надо ещё в зависимости от типа затянуть поллинг или нет, стримы или прочие обёртки, дополнительные фичи. Нет, можно всё это замечательно дублировать CTRL-C CTRL-V из класса в класс, ну или вот так извращаться, как выше. Про не-тасковые ендпоинты уже выше писал, они API Socket вполне себе реализуют, но не Task.
Я говорил про тот код, который увидел. В нем сокет используется как таск только в одном месте, причем в этом месте нужен таск, а не сокет.> CTRL-C CTRL-V
При замене наследования композицией никакой копипасты обычно нет, просто вместо использования публичного интерфейса класса идет обращение к публичному интерфейсу его публичного члена.
Впрочем, я не знаком с этой конкретной предметной областью и не думаю, что от моего теоретизирования насчет кода, который ее покрывает, будет какой-то толк.
Сокет вообще как таск живёт своей жизнью - он не обязательно прибит к конкретному родителю, всё зависит от задачи. В самом простом случае родитель - это таск протокола, но в сложных случаях там могут быть дочки, которые выполняют одну задачу в рамках конкретного протокола. Например разобрал команду SMTP в протокольном модуле - отдал сокет приёмнику данных, отработает - вернёт сокет.
Ну или например увидел в начале PROXY-протокол - отдал разбирать PROXY, разобрал, отдал SMTP.
И т.д. и т.п.
Все это доживает последние дни. Ведь слышим веб, подразумеваем JS, причем, как бэкэнд, так и фронтэнд.
> слышим веб, подразумеваем JSВы - да. Просто не торопитесь обобщать свой хайп до мейнстрима.
Сейчас лично для меня самое неудобное в создании сайтов - это то, что все инструменты для сборки фронта работают на JS, причем постоянно подпрыгивают за новинками и поэтому работают через жoпу.
> Сейчас лично для меня самое неудобное в создании сайтовЭто твои проблемы. П.с. слово "сайты" лишь говорит, что к коммерческой разработке ты имеешь отношение примерно никакое.
соглашусь, но, другого же способа рилтайм обновления веба и нет никакого иного, ведь так? меня вот, если честно, тож наламывает что надо жс учить, чтоб свой бэк на пыхе актуализировать, а что делать?
> тож наламывает что надо жс учитьНе "тож". Изучение языков, которые используешь - это логично и необходимо.
Но вот разборки с очередным убер-монстром, навалянным единственно ради того, чтобы скомпилировать твой код, но постоянно хватающимся за недозрелые технологии и ломающим то, что вчера работало... это раздражает.
Да-да-да. Пыхыпэ переехал Перл, АСП, ЖСП, КолдФьюжен, Руби. Скоро и Нода туда же отползет.
Отползёт, но не до конца - с нодой удалось попасть в хитрую нишу, когда фронтендщики начали костылить прочее из того, что умеют. Другое дело, что всё это исполняется на по сути моновендорном, да ещё и браузерном, движке кривого-косого по сути своей JS, и поэтому представляет из себя феерический костыль как по рахитектуре так и по перспективам.А пых жил и жить будет, потому что пых - это помимо языка ещё и очень удобная обёртка из коробки над толстенной массой низкоуровневых сишных либ, сдобренная именно тем, чего для работы с ними обычно и не хватает. Правда в последнее время, повторюсь, всё свернуло куда-то, кхм, в Javy или просто в афедрон, но всё равно ок.
> Отползёт, но не до конца - с нодой удалось попасть в хитрую нишу, когда фронтендщики начали
> костылить прочее из того, что умеют.как будто им на пехепе кто-то мешал?
там скорее ниша именно в бесконечной помойке лефтпадов - да, первым начал именно пехепе, но до такой простоты хуже воровства все же не дотянул.
> и поэтому представляет из себя феерический костыль как по рахитектуре так и по перспективам.
напомню, чем в (поделке на игого) grafana заменили (внезапно, ставший неподдерживаемым лефтпад) создавалку, фак... снапшотов графичков?
А тут - всего лишь js от него. Все, расслабься - для современной индус-трии именно такие решения и являются наиболее оптимальными.
Ну COBOL уже лет 40 хоронят, а 6.4 вышел в мае прошлого года. Legacy он такой, не убиваемый.
На PHP не программировал лет 10. Там наверно уже изменений как у инопланетных технологий. Верно?
так-то да. пытается на java похожим быть.
единственная реальная проблема в php - отсутствие искоробочной асинхронщины/параллельщины. ну и типизация массивов пригодилась бы.
> типизация массивов пригодилась быв классах это всё делается - инпут обрабатывать и бд правильную архитектуру - это все равно ручками всё
> отсутствие искоробочной асинхронщины/параллельщины
да, так бы и не было повального жс везде
Скорее подход поменялся. Если раньше, во времена 4 пыхи, она была шаблонизатором, то теперь это монструозное нечто, где фреймворк на фреймворке фреймворком погоняет.
Пых это как раз то место, где вообще фреймворки не нужны по сути.
Но мир смузи без монструозных конструкций не умеет.
Последний раз писал на PHP4, застав ещё PHP3. Но потом вернулся обратно на Perl, благо, работы хватит до пенсии, тем более, осталось не много :)
Лучший язык снова обновился, а это значит я не умру с голоду, и буду дальше получать 5к евро, чисто благодаря тому что пхп существует.
Граждание, почему PHP не используется в банковской отрасли? Или используется?
И второй вопрос, если PHP так стремится быть похожим на Java, сможет ли он её где-нибудь потеснить?
А зачем тащить это хлам в финансовую сферу? В энтерпрайзе рулит c#.
Почему сразу хлам-то?
Потому что сертификацию будет пройти очень сложно.
Но для вебни - используется, почему нет.
Те же payment gateways и вёб-платёжки на пыхе встречаются.