Официально состоялся (http://php.net/archive/2015.php#id2015-12-03-1) релиз языка программирования PHP 7 (http://php.net/),
вобравший в себя изменения, подготовленные в рамках проекта PHPNG. Новая ветка отличающейся кардинальной переработкой некоторых подсистем, значительной порцией новых возможностей (http://php.net/manual/en/migration70.new-features.php) и наличием изменений (http://php.net/manual/en/migration70.incompatible.php), нарушающих совместимость. Скачок в номере версии не только подчёркивает значительность релиза, но и связывается с переходом к новой нумерации выпусков, при которой разработчики избавились от лишней цифры в значительных релизах (7.0 вместо 5.7.0).Ключевые улучшения (http://php.net/manual/en/migration70.php) в PHP 7:
- Существенное увеличение производительности, благодаря применению (https://www.opennet.me/opennews/art.shtml?num=39724) новых методов организации работы с памятью и переходу на новые структуры хранения данных. В некоторых тестах PHP 7 до двух раз быстрее PHP 5.6;
- Целостная поддержка 64-разрядных типов на 64-разрядных системах. В том числе возможность использования строк, размером до 2^31 байт, поддержка 64-разрядных значений integer при работе в Windows, поддержка больших файлов в 64-разрядных сборках.
- Возможность обработки через исключения многих ошибок, ранее приводивших к принудительному завершению работы;- Новый оператор "?? (https://wiki.php.net/rfc/isset_ternary)", позволяющий определить альтернативное значение, в случае если неопределён первичный объект присвоения. Например, для присвоения пустой строки, если не заполнен элемент ассоциативного массива теперь вместо isset($_GET['mykey']) ? $_GET['mykey'] : '' можно указать $_GET['mykey'] ?? "";
- Возможность явного определения (https://wiki.php.net/rfc/scalar_type_hints_v5) скалярных типов int, float, string и bool для аргументов и значений функций (например, "function foo(int $abc): int").
- Режим жесткой проверки типов, включаемый директивой "declare(strict_types=1)", при котором несоответствие типа передаваемого функции или возвращаемого функцией значения будет приводить к ошибке.
- Новый оператор комбинированного сравнения "<a href="https://wiki.php.net/rfc/combined-comparison-operator"&... с реализацией поведения, похожего на strcmp() и version_compare(), но через использование типового синтаксиса операторов сравнения. В частности, новый оператор позволяет не только проверить идентичность операндов, но и оценить какой из них больше другого (0 - равны, 1 - левый больше, -1 - правый больше);
- Поддержка анонимных классов;
- Поддержка группировки определений (https://wiki.php.net/rfc/group_use_declarations) в операторе use (например, use Doctrine\Common\Collections\Expr\{ Comparison, Value, CompositeExpression };);
- Новый метод Closure::call();
- Дополнительный синтакс для встраивания unicode-строк \u{xxxxxx};
- Поддержка задания массивов констант в операторе define();
- Возможность (https://wiki.php.net/rfc/context_sensitive_lexer) использования зарезервированных ключевых слов в новых контекстах (например, можно определить функцию forEach и она не будет пересекаться с оператором foreach);
- Новый синтаксис "yield from выражение" для делегирования (https://wiki.php.net/rfc/generator-delegation) фукциями-генераторами операций в перемещаемые объекты и массивы.
- В дополнение openssl добавлена поддержка TLS-расширения я ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Neg... (Application-Layer Protocol Negotiation) для согласования протоколов уровня приложений, используемых для обеспечения защищённого соединения. Используется в SPDY и HTTP/2;
- Унификация (https://wiki.php.net/rfc/uniform_variable_syntax) синтаксиса определения переменных и переход к использованию AST (https://wiki.php.net/rfc/abstract_syntax_tree) (Abstract Syntax Tree). Изменение некоторой редко используемой семантики комбинирования переменных (например, $foo->$bar['baz'] теперь интерпретируется как ($foo->$bar)['baz'], а не $foo->{$bar['baz']}).
- Прекращение (http://php.net/manual/en/migration70.deprecated.php) поддержки конструктуров в стиле PHP 4, в которых имя конструктора совпадает с именем класса. Также прекращена поддержка статических вызовов нестатических методов;
- Прекращение поддержки старых и не поддерживаемых вызовов SAPI и расширений:
sapi/aolserver, sapi/apache
sapi/apache_hooks,
sapi/apache2filter,
sapi/caudium,
sapi/continuity,
sapi/isapi,
sapi/milter,
sapi/nsapi,
sapi/phttpd,
sapi/pi3web,
sapi/roxen ,
sapi/thttpd,
sapi/tux,
sapi/webjames,
ext/mssql и
ext/sybase_ct;URL: http://php.net/archive/2015.php#id2015-12-03-1
Новость: http://www.opennet.me/opennews/art.shtml?num=43449
>> Скачок в номере версии не только подчёркивает значительность релиза, но и связывается с переходом к новой нумерации выпусковА как же позорный отказ от полноценной поддержки юникода, обещанный в шестой версии? Так и будут горе пхписты мучиться с mbstring.
А что не так? Нет юникода? Ну так и 6-ой версии нет:)
Ну так в этом и суть. Отсутствие юникода это позор, для нового интерпретатора в 2015 году.
Юникод не отсутствует. Отсутствует его прозрачная поддержка для строк. Ну и я не уверен, что хоть один язык может похвастаться _полной_ поддержкой юникода.
> ... Ну и я не уверен, что хоть один язык может похвастаться _полной_ поддержкой юникода.java?
Такие же двубайтовые символы как в винде и C#.
Ну так выбор-то небольшой — либо геморрой с составными символами, либо дикий оверхед по памяти для 99.999% строк.
x2 для worst case - это дикий оверхед??Ну-ну.
Ты не понял: не x2 для worst case, а x4 для всего. А иначе - геморрой с составными символами.
Perl
У него скорее всего лучшая, но все-таки неполная.
Rust
Python3 ?
не, она там ужасная и костыльная. (вспоминая свой питоновый скрипт для перекодировки id3-тэгов и то, какие проблемы вылезали при переписывании его под трёшку)как надо -- см. тот же go.
> не, она там ужасная и костыльная.Что конкретно там "ужасного"?
Go
D
> Dтоже ололо. там внутри-то юникод, а вот при попытке взаимодействовать с консолью (разными локалями и ос) начинается адский ад на пустом месте. а в go почему-то всё просто работает.
Плохому танцору...
ТОЧНО!
Плохому танцору - D!
swift
C# :)
С++/Qt версии 4 и 5
Ruby
Ruby - единственно правильное решение. Кодировка строки хранится вместе со строкой (условно говоря, как в XML и т.п.). Если нет - то строка это набор байтов. Про Java и С# могут говорить только те, кто не выходил дальше своей скорлупы (или яслей). Питон - это замечательный пример того, как благие желания ведут в ад. Перл (его отцы-основатели) окончательно свихнулся - смотри ответ Тома Кристиансена на stackoverflow - это "сложно, потому невозможно, точнее можно, но только избранным."
Только авторы perl решают сейчас такие проблемы поддержки юникода, о которых остальные еще даже не задумывались.
А вы у нас по моему из mail.ru если я нечего не путаю,это не оскорбление)))
Haskell - полная поддержка.
Полная поддержка какой версии юникода? И точно ли полная?
c++
даже в php поддержка юникода лучше
В чем проблема: хотите отличать обычные строки от Unicode, то определите для себя класс Unicode и держите в нем свои методы по обработке строк. Уже который год устраивают истерику над несуществующей проблемой.Что до модификатора u"Строка в Unicode", то с одной стороны очень удобно, но опять таки зачем помещать данные внутри исходного кода? Храните во внешних ресурсах и читайте каким-нибудь UnicodeReader, который будет медленным в вашем конкретном одном случае, но не будет аффектать все другие.
Я пока вообще не услышал ваших доводов в пользу строк юникод, только ссылку что стыдно там что-то в 2015 году иметь... Если действительно имеете идею интересную и готовую к реализации подавайте документ к рассмотрению и принятию, а не нойте нам...
>>В чем проблема: хотите отличать обычные строки от Unicode, то определите для себя класс Unicode и держите в нем свои методыИменно так, PHP это один большой костыль состоящий из кучи разношерстных велосипедов...
>>>В чем проблема: хотите отличать обычные строки от Unicode, то определите для себя класс Unicode и держите в нем свои методы
> Именно так, PHP это один большой костыль состоящий из кучи разношерстных велосипедов...А в чем велосипед? У Вас какие-то особенные требования к обработке цепочек байт. Ну вот и реализуйте его самостоятельно. Для Вас сделали специальные библиотеки вроде mbstring вполне себе адекватное решение.
Вообще не пойму в чем проблема? Расскажите, что конкретно не устраивает и PHP Team может реализовать поставленную задачу...
Другое дело, что вместо реальной обратной связи Вы сидите на далеком форуме от разработчиков и обижаетесь, что Ваше мнение не предугадали в момент дизайна системы.
> Для Вас сделали специальные библиотеки вроде mbstring вполне себе адекватное решение.Почему эти библиотеки не предоставляют классы типа Unicode из коробки? И нет, библиотеки с функциями с C-подобной семантикой -- ни разу не адекватны в высокоуровневом языке.
> Расскажите, что конкретно не устраивает и PHP Team может реализовать поставленную задачу...
Не реализуют, потому что Расмус (tm) Вот тут человек предлагает адекватные объектно-ориентированные строки:
http://www.serverphorums.com/read.php?7,1145064,1146330#msg-...
> $s = strripos($s, 'a'); // works in PHP 5+
> $s = $s->lastOccurance('a', 0, CASE_INSENSITIVE); // works in PHP 7+А вот Расмус говорит дальше, что ему strlen нравится потому-что по-сишному:
> Plus, if you are a C dev, much like strlen(), these are simply the names you expect, or at least they are instantly recognizable to you
Немного вырвано из контекста, но народ потер про OO API и так ничего не случилось.
> Почему эти библиотеки не предоставляют классы типа Unicode из коробки? И нет,И да. Потому что скорее всего массово это никому не нужно... Было бы нужно - давно было бы расширение, реализующее эти классы.
> А вот Расмус говорит дальше, что ему strlen нравиться потому-что по-сишному:
>> Plus, if you are a C dev, much like strlen(), these are simply the names you expect, or at least they are instantly recognizable to youВыменно. C-подобный синтаксис и есть то, что сделало PHP крайне используемым и популярным.
>[оверквотинг удален]
>> Расскажите, что конкретно не устраивает и PHP Team может реализовать поставленную задачу...
> Не реализуют, потому что Расмус (tm) Вот тут человек предлагает адекватные объектно-ориентированные
> строки:
> http://www.serverphorums.com/read.php?7,1145064,1146330#msg-...
>> $s = strripos($s, 'a'); // works in PHP 5+
>> $s = $s->lastOccurance('a', 0, CASE_INSENSITIVE); // works in PHP 7+
> А вот Расмус говорит дальше, что ему strlen нравится потому-что по-сишному:
>> Plus, if you are a C dev, much like strlen(), these are simply the names you expect, or at least they are instantly recognizable to you
> Немного вырвано из контекста, но народ потер про OO API и так
> ничего не случилось.Вы недовольны тем, что свободный инструмент Вам предоставленный не удовлетворяет Ваши ожидания?
Тогда переведем вопрос в другую плоскость: Сколько Вы готовы заплатить за реализацию класса Unicode из коробки?
Удивительно, так как автор свою позицию обозначил: хочет он использовать C подход длинны строк (так как видимо он думает, что не только строки, но и данные можно хранить в цепочках символов и собственно я с ним солидарен - это эффективно по памяти и в определеенной степени компромис).
>> Скачок в номере версии не только подчёркивает значительность релиза, но и связывается с переходом к новой нумерации выпусков
> А как же позорный отказ от полноценной поддержки юникодаА как это можно отразить в номере версии?
> порцией новых возможностей и наличием изменений, нарушающих совместимостьСугубо моё мнение, но это самый сильный аспект, который может заставить выбрать другой язык при планировании разработки нового проекта. Как будто язык молодой и в стадии подготовки стандарта и не серьёзные дяди его пилят, а школьники ...
Скажи это питону
Да ладно вам! Все нормально уже в Python 3. 2 год выпускаем новые проекты только на нем. 90% библиотек уже нормально работают под Python 3
> Да ладно вам! Все нормально уже в Python 3. 2 год выпускаем
> новые проекты только на нем. 90% библиотек уже нормально работают под
> Python 3Уже лучше чем было, перелазят потихоньку но слабо. Мне куда больше нравиться какую стратегию приняли в Ruby(хотя и не любитель) сначала вылазят варнинги но код работает, а в следующей версии код перестает работать. Просто и лаконично.
В Python такая же система принята с 2.(черти какой версии). Тоже сперва варнинг, потом постепенный отказ. При переходе на 3 до сих пор поддерживают две ветки. При этом в 3 не только print поменяли и это стоило сделать давно :) Так что все очень лояльно.
Ну отлично тогда, хотя с переходом на 3к получилось не айс
> Ну отлично тогда, хотя с переходом на 3к получилось не айсЧего не айс дубина? Дали людям без гимора перейти, не торопясь.
А теперь внимание - поставь в уютную __любой__ из современных дистров Линукс. Там 100% будет питон. И в 95% по дефолту он будет _третьей_ версии. А в некоторых ... второго уже не будет! Мол надо - сам ставь из реп :)Из софта который не портанули остался только fabric ... но это скорее хорошо чем плохо! :)
Вася, у вас болезненный детские воспоминания фаллических предметов, с этим к психологу, там детски травмы поправят и помогут дальше нормально жить.
Сколько лет длился переход от второй версии к третей? Ну давай CentOS 7 по ставлю и буду возмущаться второму питону или debian 8, а это наверное не современные линукс дистрибутивы.
Вот когда выйдет Убунта 16.04 вот тогда и сможете балаболить. И кстати fabric не одинок, еще ansible на втором питоне и список можно продолжить.
> поставь в уютную __любой__ из современных дистров Линукс. Там 100% будет питон. И в 95% по дефолту он будет _третьей_ версииrhel 7 достаточно современный? или ubuntu 14.04? в обоих второй по умолчанию.
или вы про арчики и прочую маргинальщину?
>> Да ладно вам! Все нормально уже в Python 3. 2 год выпускаем
>> новые проекты только на нем. 90% библиотек уже нормально работают под
>> Python 3
> Уже лучше чем было, перелазят потихоньку но слабо.Да все уже перешли, выйдите из анабиоза.
> Мне куда больше нравиться
> какую стратегию приняли в Ruby(хотя и не любитель)Угу. Называется эта стратегия - PEP 5.
Сказать им, что они молодцы и заботятся о своём продукте, хоть и о параллельном (т.е. не о старом, а именно о параллельном), аж до 2020 года (не факт, что не продлят) https://hg.python.org/peps/rev/76d43e52d978 , в то время как пхп после генерации нового релиза о старом забывают через 2 года, что крайне не дружелюбно для больших и серьёзных проектов http://php.net/supported-versions.phpПроблема PHP - вышли новые штуки, удалены старые, ТЫ ОБЯЗАН слушаться, выполнять! (вспоминаются двухтысячные, переход с 4 на 5 версию, когда куча CMS посыпались по всему bynthytn-миру всего за один день :) ) И в принципе у тебя нет возможности этому противостоять (не обновляясь, ты лишаешься заплаток в безопасности).
Вы либо не знаете предмета, либо нагло врёте. Питонщикам пришлось продлить поддержку второй ветки, они минимум 2 раза пытались её прекратить. Однако, увы, перенести весь код на 3ю версию было адски тяжело и этим не занимались ни ведущие разработчики проектов, ни разработчики библиотек. Как раз именно потому, что совместимость была порушена резко и весьма сильно.
Изменения в PHP от версии к версии чрезвычайно малы и редко необратимы: года 4 выдаются сообщения о том, что некоторая конструкция/функция будет себя вести по-другому. Надо быть достаточно упёртым, чтоб их не заметить.
> Питонщикам пришлось продлить поддержку
> второй ветки, они минимум 2 раза пытались её прекратить.Причина простая: туча пропиетарного говнокода, который никто не
хочет портировать.> Однако, увы, перенести весь код на 3ю версию было адски тяжело и этим
> не занимались ни ведущие разработчики проектов, ни разработчики библиотек.Мифическая трудность "переноса" тут никаким боком. Актуальные
проекты, тем более открытые - давно работают в python3, причем на
единой с python2 кодовой базе.(Как правило, проблему поддержки py3 проекты могут решить обычно
даже чисто механическим путем, с 2to3 (еще один привет PHP).)Трудности, по понятным причинам - возникли с тем, что никому нафиг не нужно.
> Как раз именно потому, что совместимость была порушена резко и весьма сильно.
1 (один) раз в истории языка. PHP это чуть не в минорных релизах творит...
Актуальные проекты, в том числе открытые, переносили на Python3 более двух лет, у некоторых это заняло больше пяти лет(!).Некоторые актуальные проекты на PHP уже протестированы на 7й версии, в том числе разработчиками языка.
> 1 (один) раз в истории языка. PHP это чуть не в минорных релизах творит...
это ложь.
> Актуальные проекты, в том числе открытые, переносили на Python3 более двух лет,
> у некоторых это заняло больше пяти лет(!).Говнокод есть на любом языке. Собственно, это единственная причина
подобных трудностей(помимо недостатка рук).Другое дело в том, что эти "пять лет" - проекты решали все-же не просто
задачу портирования, а задачу перевода проекта на кодовую базу, общую
для py2 и py3. Это немножко другое. PHP такое вообще умеет?!> Некоторые актуальные проекты на PHP уже протестированы на 7й версии, в том
> числе разработчиками языка.А выполняться на PHP 4 и PHP 7 с одной и той же кодовой базой - они
могут? Вот то-то. А так, портировать в python3 - тупая программа может, за
минуту а не пять лет. Я ведь же уже объяснял, нет?Для клинических идиотов: задача портирования в py3 решается механически,
вообще без необходимости в быдлокодере. Это понятно?>> 1 (один) раз в истории языка. PHP это чуть не в минорных релизах творит...
> это ложь.Ну, как минимум, не единожды.
а программы на пистоне могут выполняться на 1 и 3 версиях одновременно? Если же говорить про php 5 и 7 то таки могут. Есть полифилы для 5 версии реализующие недостающий функционал из 7.
> а программы на пистоне могут выполняться на 1 и 3 версиях одновременно?А где-то в жизни бывают вообще 1-я версия? 2.0 был выпущен в прошлом веке.
> Если же говорить про php 5 и 7 то таки могут.
Разумеется, нет, мальшик. Никакие валшебные "полифилы" не помогут если синтаксис языка поменялся. PHP это лисп что-ли?!
Все сурово на самом деле. php 5 - 2004 год. 5.3 - вообще выпущен в 2009. И PHP "разработчики"
до сих пор плачутся и не хотят обновляться из-за поломанных register_globals и прочей гадости.И никаких вам 2to3, никаких from __future__ - мартышкам велено ручками... Ниче,
труд мартышкин дешев.
> Разумеется, нет, мальшик. Никакие валшебные "полифилы" не помогут если синтаксис языка поменялся. PHP это лисп что-ли?!Нет, малыш, ты просто не в теме. У меня приличная часть старого кода переезжала между 4->5.0->5.3 без существенных изменений.
Плюс приличная часть уже "нового" объекто-ориентированного кода переехала с 5.3->5.4->5.6->7.0 без изменений.
Только что пересадил phpmyadmin с 5.6 на 7.0. Поддержка 7.0 еще "официально" не заявлена. При не совсем беглом осмотре ничего не отломалось.
Т.е. если писать нормально - всё будет нормально, обратная совместимость между ветками сильно не ломается уже давно.
>> Разумеется, нет, мальшик. Никакие валшебные "полифилы" не помогут если синтаксис языка поменялся. PHP это лисп что-ли?!
> У меня приличная часть старого
> кода переезжала между 4->5.0->5.3 без существенных изменений.Ключевая фраза "у меня".
А у меня статистика с хостингов, где клиенты воют, когда
даже минорный релиз меняется (напр. 5.3->5.4). Не было у них
машины времени, не шмогли предсказать что открутят песатели
PHP в следующем релизе. Не то что выпускники рашен пту с опеннету...> Т.е. если писать нормально
Речь была не о мерянии пиписьками по части "нормального письма", а
например об инструментах, автоматизирующих портирование кода. У Python
для того единственного случая, когда совместимость поломали - такие
инструменты *есть*.А у этого чуда - нет. Мартышкам не надо.
> Ключевая фраза "у меня".Именно. Потому что "статистика с хостингов" показывает только общий уровень квалификации клиентов твоего хостинга, и не более.
> А у меня статистика с хостингов, где клиенты воют, когда
> даже минорный релиз меняется (напр. 5.3->5.4).У нас тоже хостинг имеется, так там подняты все версии сразу, начиная с 5.2, на выбор. Зачем без спросу менять клиентам релиз движка? Или это традиция такая?
В случае PHP никто не мешает юзать для старого кода конкретную нужную версию. PHP, тьфу-тьфу, в отличие от тех же перлопитонов с руби и жабами, не тащит за собой ворох всяких гвоздями прибитых к версиям депенденсов, написанных на нём же. Рантайм практически монолитный, и не требует подгонки версий со всяких CPAN'ов.
>> Ключевая фраза "у меня".
> Именно. Потому что "статистика с хостингов" показывает только общий уровень квалификации
> клиентов твоего хостинга, и не более.Не "моего", а всех.
>> А у меня статистика с хостингов, где клиенты воют, когда
>> даже минорный релиз меняется (напр. 5.3->5.4).
> У нас тоже хостинг имеется, так там подняты все версии сразу, начиная
> с 5.2, на выбор.Во-во, и я об чем. А ведь больная идея, если все так хорошо с совместимостью и все так
просто с портированием.> В случае PHP никто не мешает юзать для старого кода конкретную нужную версию.
Так и никто не мешает. Хочешь python 1.5 - будь!
Но это уже пошли какие-то странные "достоинства"...
> PHP, тьфу-тьфу, в отличие от тех же перлопитонов с руби
> и жабами, не тащит за собой ворох всяких гвоздями прибитых к
> версиям депенденсов, написанных на нём же.Да, в PHP они просто молча отваливаются, не собираются и т.п. Такие вот зависимости
у мартышек, спешите видеть.
> Да, в PHP они просто молча отваливаются, не собираются и т.п.Щито? У меня все версии PHP (5.2/3/4/5/6, 7.0) на хостинг собираются оптом из одного RPM .spec-шаблона с минимальными отличиями, в основном касательно путей (phpXX), новых модулей в новых версиях (+ удалённых старых, например в 7.0). Ничего не отваливается, и всё собирается. Ранее собиралось в C6, и не стало хуже в C7.
Более того, pecl'овый ZendOpcache прекрасно собирается для 5.2/3/4, blitz для 5.3/4/5/6, и отдельными версиями для 5.2/7.0.
>> Да, в PHP они просто молча отваливаются, не собираются и т.п.
> Щито? У меня все версии PHP (5.2/3/4/5/6, 7.0) на хостинг собираются оптом
> из одного RPM .spec-шаблона с минимальными отличиямиМальшик, ты сторонние расширения (на C и PHP) к этой гадости попробуй
присобачить "из одного spec-шаблона".> Ничего не отваливается, и всё собирается.
Ну еще б сам PHP не собирался. На таком уровне мартышки свое
поделие, конечно, хоть как-то тестируют.
У меня такое ощущение, что ты совершенно не понимаешь не только, что другие пишут, но и что пишешь сам. Совсем. Ну и ещё нагло звездишь про то, что у тебя "статистика с хостингов", знал бы хостинговую среду - ориентировался бы получше.Я не зря написал выше про конкретные расширения РАНТАЙМА. Например для шаред хостинга их не нужно. Почти никаких - разве что zendopcache, но он для шареда тоже применим очень условно. Для себя собираю ещё пачку - от 5.0 до 5.6 ничего собственно не менялось, никаких модификаций не требовалось. В 7.0 ABI сильно изменился, но большинство расширений уже адаптированы авторами.
А никаких модулей, написанных на самом PHP, PHP за собой не тянет. Что ты, собственно, прочитать и ниасилил.
> Ну и ещё нагло звездишь про то, что у тебя "статистика с хостингов", знал
> бы хостинговую среду - ориентировался бы получше.Ну тож были не хостинги, мало ли что про них каждая собака в рунете
слыхала. Хостинг - это контора рога и копыта на арендованном дедике, ага...> Я не зря написал выше про конкретные расширения РАНТАЙМА. Например для шаред
> хостинга их не нужно.Ну это администратору их не нужно. В частности, из-за отмеченной
выше порнографии в этом адовом болоте. А вот клиентам очень даже
нужно, они такое активно просют.Так что имеем то что имеем. Стандартные модули собираются, а дальше - как
повезет.> А никаких модулей, написанных на самом PHP, PHP за собой не тянет.
Негодяям-пользователям иногда надо, понимаешь. Даже мартышкам
стандартной библиотеки не хватает, прикинь! А чо, кто-б сомневался - и в
Python порой не хватает, а евонная stdlib поболее будет...
Ни одного клиента, просящего какой-то совсем специфичный экстеншн, в тикетах не было. Клиентов - тысячи, хостингу лет десять (лично я его веду два года). Может потому, что практически все builtin'ы, кроме небезопасных для шареда, собраны.С другой стороны, если вдруг (нереальный вариант) попросят - в случае PHP5 точно знаю, что соберётся xD Хотя шансов на то, что попросят - 0. Большинство тех, кто идёт на шаред, юзают готовые движки (которые разрабатываются под стандартные экстеншны), или разрабатывают строго под стандартные экстеншны.
Более того, опять же в случае PHP мне сложно представить какую-то жуткую модификацию к рантайму, которая могла потребоваться бы не на специально заточенном под задачу VPS, а на шареде. Типовой шаред - один-два сторонних модуля в лучшем случае. Некоторые все встроенные экстеншны собирают как .so, но статическая сборка на практике для шареда оказывается куда эффективнее.
Вот просто видно, что вы с устройством PHP знакомы едва. Там совсем другая парадигма, в третий раз повторю: рантайм PHP содержит всё нужное (и включенное опциями) сразу после сборки, при этом априори линкуется с нужными C/C++ библиотеками, и за собой кучу гвоздями прибитых к версии рантайма зависимостей на собственном языке (этим болеют: perl, ruby, python, java) не тянет.
И да. ВСЁ, что написано на собственно PHP - уже строго пользовательский код, в окружение сервера он не входит. Это ещё одна причина, по которой PHP ныне - самый удобный рантайм для приложений на шаредах. Если perl ещё как-то выживает в шаредах через CGI (только с матюгами и подгонкой версий, а-ля: не та = не работает и не будет), то с теми же питонами и рубями в силу тонн зависимостей приходится собирать по целому килотонному индивидуальному окружению на клиента, а это мазохизм.
Но, тьфу-тьфу, перлорубипитонового хостинга у меня давно нет, и никогда (надеюсь) более не будет.
> Клиентов - тысячи, хостингу лет десятьЯ ж и говорю, шаред на арендованном дедике... Видать, угадал)
> Может потому, что практически все builtin'ы, кроме небезопасных для шареда, собраны.
Нет, чо, правда? И даже всякие eaccelerator, xcache (тьма их) у вас в builtin'ах очутились?
> статическая сборка на практике для шареда оказывается куда эффективнее
Чем бы дитя не тешилось...
> Вот просто видно, что вы с устройством PHP знакомы едва.
Да куда мне.
> Там совсем другая парадигма, в третий раз повторю: рантайм PHP содержит всё нужное
> (и включенное опциями) сразу после сборки"Другая парадигма" - "all batteries included". Ее много кто исповедует,
включая собственно Python. И надо сказать, что с куда большим
успехом (стандартная библиотека PHP вне веб - убожество).Хорошо, конечно, повторять мантру про "все нужное", но такого быть
не может. И тогда возникают закономерные вопросы - как это дело
можно расширять и что у него с зависимостями. По сравнению со
взрослыми языками - там у PHP п*па.> И да. ВСЁ, что написано на собственно PHP - уже строго пользовательский
> код, в окружение сервера он не входит.Можно я не буду верить на слово гуру с опеннету? Большинство
дистрибутивов, к примеру, имеют иную точку зрения (Debian, например).Да какая к черту разница как _это_ называть. Скомпилированное расширение
ломается или оное на PHP - выхлоп одинаков.
>> Клиентов - тысячи, хостингу лет десять
> Я ж и говорю, шаред на арендованном дедике... Видать, угадал)Не угадал. Компанейский хостинг в принадлежащим компании ДЦ.
> Нет, чо, правда? И даже всякие eaccelerator, xcache (тьма их) у
> вас в builtin'ах очутились?Этим глючным говном мамонта кто-то реально ныне пользуется? Ни одной заявки от клиентов на подобное за последние годы. Впрочем, для кеша кода давно есть opcache. Ну и кеши eaccelerator/xcache на шаредах - прямой путь к проблемам.
Хотя ради честности скажу, что opcache у нас таки включен. Всё жду бэкпорта файлового режима opcache из 7-ки в экст для 5-ки, после чего переключу кеш на всех инстансах в file-only, и успокоюсь.
> успехом (стандартная библиотека PHP вне веб - убожество)
Стандартная библиотека PHP вне вёба на практике с успехом заменяет все руло^W километры туал^W кода на python/ruby/java для оных для большинства более-менее сложных приложений, не говоря уже о примитивных.
---
Самая простая задача: привернуть MySQL. В случае питона - немножко ыыы, надо тащить рулончик Connector/Python, но нормально. В случае руби - ад аццкий + проблемы с совместимостью в зависимости от версии библиотеки. Имеются две несовместимых версии. В итоге если что-то из зависимостей завязано на mysql, а что-то на mysql2 - гмкхм... Ну и опять же: оба экста - "выносные" рулончики, поддерживаемые сторонними разработчиками.
В случае PHP же в задаче с MySQL ничего делать не надо - все расширения встроенные, расширение mysqli уже бородатое, но ничего делать не надо. Да, оригинальное расширение mysql задепрекейтили, и в 5.6/семёрке его уже нет, но суть в том, что оно уже отжило даже де факто - все ушли на mysqli (благо это просто). PHP, кстати, один из немногих (если не единственный вообще, не уверен), имеющих нативную реализацию протокола mysql (mysqlnd) без необходимости тащить внешние библиотеки. Поддерживается всё это хозяйство разработчиками PHP.
Итого:
PHP = PHP -> mysqli (PHP) -> mysqlnd (PHP), ну или PHP -> mysql (PHP) -> libmysqlclient (oracle/mariadb/...)
python = python -> connector/py (oracle) -> libmysqlclient (oracle/mariadb/...)
ruby = ruby -> mysql/mysql2 (???) -> libmysqlclient (oracle/mariadb/...)В случае PHP всё вообще красиво. В случае python - уровнем больше, но по крайней мере оба уровня взаимодействия с БД всерьёз поддерживаются. В случае ruby всё плохо - уровень "прокладки" между языком и MySQL только third-party.
Плюс в случае PHP при сборке с libmysqlclient мы "автоматически" получаем ещё несколько возможных внутренних db-independent интерфейсов с биндингами к libmysqlclient, если хочется абстракции. В случае прочих языков это всё будет только навесное.
> Можно я не буду верить на слово гуру с опеннету?
Можно, твои проблемы.
>>> Клиентов - тысячи, хостингу лет десять
>> Я ж и говорю, шаред на арендованном дедике... Видать, угадал)
> Не угадал. Компанейский хостинг в принадлежащим компании ДЦ."Тысячи клиентов" - маловато при этом раскладе, однако. Тут речь о десятках тысяч,
это как минимум.>> Нет, чо, правда? И даже всякие eaccelerator, xcache (тьма их) у
>> вас в builtin'ах очутились?
> Этим глючным говном мамонта кто-то реально ныне пользуется?Это просто пример сторонних расширений, мягко говоря популярных в свое время.
> Ну и кеши eaccelerator/xcache на шаредах - прямой путь
> к проблемам.Не хочешь проблем - не заводи хостинг с PHP.
>> успехом (стандартная библиотека PHP вне веб - убожество)
> Стандартная библиотека PHP вне вёба на практике с успехом заменяет все руло^W
> километры туал^W кода на python/ruby/java для оных для большинства более-менее сложных
> приложений, не говоря уже о примитивных.Хочу аналог maxima. Заменит?) Чо-то тухло с заменами на PHP, наверно
все еще на свою замечательную stdlib медитируют.> Самая простая задача: привернуть MySQL.
И с какого боку этому надо быть в stdlib? Самая задача для вебки. В stdlib, если
правильно помню, есть модуль для sqlite с полность аналогичным API.Все-таки "all batteries" не стоит воспринимать совсем уж буквально, иначе
stdlib превратится в мешанину всех когда-либо созданных модулей.(Про руби пусть кто-то другой отповедь даст, подозреваю что и
здесь все не менее далеко от реальности.)> В случае PHP же в задаче с MySQL ничего делать не надо
Ну да, потому что это язык под LAMP.
А с unittest там все так же плохо, от слова "нет совсем"? А ast действительно школие
в stdlib полагает ненужным? Или ты мне щас расскажешь как в PHP нормальную
bigint арифметику поиметь, без синтаксиса "как в C". (Правда, это уже больше
плевок в сторону языка самого по себе.)
>> Как раз именно потому, что совместимость была порушена резко и весьма сильно.
> 1 (один) раз в истории языкаой, не помните вы историю изменений между 2.2 и 2.5, например
> ой, не помните вы историю изменений между 2.2 и 2.5, напримерметаклассы. Это пример резко? Смех в детском садике.
вы тоже не помните. переход на 2.5 с 2.2-2.3 был мучительным, очень много софта долго допиливали до того, чтобы оно на новых питонах вообще работало
С учётом того что нарваться на это практически достаточно сложно, вероятность близка к нулю...
Тут одно из двух: или поливаем грязью язык за нелогичность или терпим несовместимые изменения при попытке это исправить. Я за улучшения.И на мой взгляд, изменения не настолько и ужасные, чтобы нельзя было переделать. Язык стал строже и логичнее.
> Язык стал строже и логичнее.
> оценить какой из них больше другого (0 - равны, 1 - левый больше, -1 - правый больше);В этом весь PHP.
Впервые увидел такую конструкцию?
> Впервые увидел такую конструкцию?Нет, в отличие от вас. Нормальные люди возвращают отрицательное значение, когда левый операнд меньше правого, а не наоборот. Это же математика, знак разности, но пэ-хэ-пэшные гуманитарии не могут в математику…
> Нормальные люди возвращают отрицательное значение, когда левый
> операнд меньше правогоКто-то запутался? man strcmp().
> но пэ-хэ-пэшные гуманитарии не могут в математику…Да нет, это не-пэхэпэшный недогуманитарий не вдолбился в написанное. "Левый меньше правого" = "Правый больше левого". Что, собственно, и написано.
> -1 - правый больше
> Нормальные люди возвращают отрицательное значение, когда левый операнд меньше правогоНаркоман?
> Язык стал строже и логичнее.explode(опция, обрабатываемая строка)
strstr(обрабатываемая строка, опция)
str_replace(поиск, замена, обрабатываемая строка, опции)Логичность так и прёт из всех щелей, по вызовам встроенных функций..
Вы путаете логику и унификацию.explode(опция, обрабатываемая строка) - "разделить по подстроке строку" - логично?
strstr(обрабатываемая строка, опция) - "найти подстроку начиная с" - логично?
str_replace(поиск, замена, обрабатываемая строка, опции) - "найти значение, заменить на значение в строке, вывести в переменную" - логично?
Только для обладающих памятью канарейки. "Лепим костыль, некогда думать!"
> Только для обладающих памятью канарейки. "Лепим костыль, некогда думать!"Нет, "Лепим костыль, некогда думать!" — то, чем руководствовались авторы языка, когда писали эти функции.
чемто напоминает асм синтаксис АТ и Интел )))
Угу. Вот только синтаксис АТ и Интел — это два разных синтаксиса, и свою внутреннюю логику каждый из них соблюдает, хоть и игнорирует логику другого. Пых же нарушает свою собственную логику на каждом шагу.
src,dstdst,src
> можно указать $_GET['mykey'] ?? "";$_GET['mykey'] ?? null;
>> можно указать $_GET['mykey'] ?? "";
> $_GET['mykey'] ?? null;а смысл какой ? если всё равно обернётся это всё в условие на проверку )))
В PHP специально ввели отдельный тип данных null для указания пустых строк, что бы вместо них не писали одинарные кавычки, и тем более двойные.
null не имеет никакого отношения к пустым строкам. Это отдельный тип, указывающий отсутствие любых данных. Который, к тому же, не виден в isset. Если нужна пустая строка - надо писать именно пустую строку.
> null не имеет никакого отношения к пустым строкам. Это отдельный тип, указывающий
> отсутствие любых данных.Про это я знаю, но для int или float проще указать 0, для bool логичнее false, и только указатель пустой строки '' выглядит не выразительно.
> Который, к тому же, не виден в isset.Вот это для меня новость. Весьма странное поведение.
> Если нужна пустая строка - надо писать именно пустую строку.Мне показалось, что в этом примере как раз не сколько нужна именно пустая строка, сколько указание на отсутствие данных, что бы это не вызывало ошибку уровня notice.
А в каких случаях, по вашему, нужно использовать именно null?
> А в каких случаях, по вашему, нужно использовать именно null?В качестве возвращаемого значения, если данные, допустим, не обнаружены.
>> А в каких случаях, по вашему, нужно использовать именно null?
> В качестве возвращаемого значения, если данные, допустим, не обнаружены.Согласен. Но в данном примере как раз аналогичный случай.
> Про это я знаю, но для int или float проще указать 0,Точно? а +0 или -0 (для float) "логичнее"?
> для bool логичнее false,
Какая-то "логика" у тебя девчячья:)
Вы что сказать-то хотели?
>> можно указать $_GET['mykey'] ?? "";
> $_GET['mykey'] ?? null;лучше было бы если можно было бы заранее описывать какие мандатори суперглобалы должны уже существовать до выполнения скрипта, иначе отвергать запрос самим пхп.
Продолжают копировать фичи перла 10летней давности. Глядишь лет через пять догадаются разделить массивы и хэши.
Ну справедливости ради некоторые из этих фич появились в перле меньше, чем десять лет назад, а некоторые отсутствуют в core до сих пор и есть только в виде модулей.
Уррааааа!!!
А сколько новых дырок пофиксили? Почему ни слова? Не верю, что 0.
> А сколько новых дырок пофиксили? Почему ни слова? Не верю, что 0.Пофиксили 0, зато много добавили.
Я нуб, так что кидайде камнями сильнееВозможность явного определения скалярных типов int, float, string и bool для аргументов и значений функций (например, "function foo(int $abc): int").
Я правильно понимаю, что используя эти типы, теперь пхп будет меньше жрать памяти, то есть теперь в памяти булево значение будет занимать не 64(32) бита, а 1 бит?
На уровне процессора невозможно адресовать память по битам. То есть для чтения нужного бита надо извлечь из памяти все слово и произвести операцию тестирования бита. Для записи опять таки понадобится модифицировать все слово. А для поиска расположения бита для конкретной переменной придется хранить дополнительную информацию, которая займет столько же места, что и значение переменной без упаковки. Так что упаковывание нескольких булевых значений в одно слово невыгодно в подавляющем большинстве случаев.
> На уровне процессора невозможно адресовать память по битам. То есть для чтения
> нужного бита надо извлечь из памяти все слово и произвести операцию
> тестирования бита.Когда проходили x86-инструкцию BT - прогулял урок?
Замечательная иллюстрация моего тезиса:"Изучение ассемблера вовсе необязательно для понимания принципов работы железа и наоборот, изучивший ассемблер может так и не понять особенности работы процессора, памяти, шины итд.".
Вот в этом весь ПХП. Его пользователи (программистами не позволяет назвать их квалификация) абсолютно не понимают, что пишут, и дальше своего локального апачика и ff не видят. А потом sql-injection на каждом шагу, неподдерживаемый код и браузеры жрут по 500 метров на вкладку.Извини, ты наверняка отличный парень, ничего лично негативного к тебе не имею, добра тебе. Но имею негатив к отрасли так назваемой web-разработки, фундамент которой был сделан из PHP.
>и браузеры жрут по 500 метров на вкладкукак это относится к похапе?
вывести ерунду можно и средствами швитого питона и руби.
> браузеры жрут по 500 метров на вкладкуо, иксперд
Лично меня, как нифига не кодера, порадовало вот это:
>Существенное увеличение производительности, благодаря применению новых методов организации работы с памятью и переходу на новые структуры хранения данных. В некоторых тестах PHP 7 до двух раз быстрее PHP 5.6;
Самое главное чтобы проект на 5.6 без проблем взлетел, а то толку от этого ускорения, если ничего не работает. С 5.4 на 5.6, к примеру, сломали обратную совместимость. Надеюсь в этот раз такого не повторится.
В этот раз придётся тестировать программу заново у переписывать участки с устаревшим кодом.
> Надеюсь в этот раз такого не повторитсяНу-ну.
> Новая ветка отличающейся <...> и наличием изменений нарушающих совместимость.
Можете не бояться, индусы + студенты все равно запилят таким образом(читай засрут всю память) что даже в супер простом проекте будет создаваться овер 100500 объектов из плагинов которые они наподключали(чтобы не заморачиваться и уменьшить количество кода).
Когда у языка ломается обратная совместимость - это становится другой язык. Получается php 5.6 и php 7.0 - разные языки. По логике вещей они должны существовать и развиваться параллельно. Но мы то понимаем что так не будет. Поэтому есть повод задуматься, а нафига переписывать всё на php 7.0, если появится еще один новый язык 7.1, потом 7.2 и т.д.. И каждый раз разработчики разработчики будут признаваться в кривости своих рук и убеждать нас что вот в этот раз точно всё сделано правильно! А поддержка прошлых версий будет сворачиваться.
есть две модели развития - с параллельной поддержкой и без. Это вторая. И при чем тут кривость разработчиков или кого либо еще? Тем более, что вас лично никто не "убеждает в том, что сделано правильно". Это сделано иначе, чем вы ожидали, и только :)
> Тем более, что вас лично никто не "убеждает в том, что сделано правильно".Дело же не в этом. Дело в том, что то, что сделано, уже сделано, и миллионы разработчиков используют это таким, какое оно есть.
> есть две модели развития - с параллельной поддержкой и без. Это вторая.Причем здесь модели разработки? если вам пишут что это два отдельных языка. Говорить о них как о чем то общем - неправильно. Поэтому нет никакого морального права называть PHP 7 именно PHP. Cronos же на назвала Vulkan пятым OpenGL'ом. Однако так было сделано, и теперь язык php 5.6 будет подвергаться гонению и искоренению, вместо развития.
>Дело же не в этом. Дело в том, что то, что сделано, уже сделано, и миллионы разработчиков используют это таким, какое оно есть.не о чем. Вообще, если уж серьезные терки такие, то форкните и пилите свою ветку. Только вот не надо ныть про то, что кто-то кому-то чего обязан. Были дискуссии и все изменения были выбраны на голосовании. Кстати, я догадываюсь, что из тех, кто пилит что-то на жумла/вордпресс-подобных системах. Если бы вы делали что-то свое, вы бы были только рады :)
>Причем здесь модели разработки?
при том. Почему вы вспомнили про OGL, а про DirectX постеснялись упомянуть. Ну или про Python.
Назовите систему с DirectX 12, но бед DirectX 11
> Только вот не надо ныть про то, что кто-то кому-то чего обязанБогатое у вас воображение
да ты упоролся. Сравни например perl5 с perl6 - вот там действительно "поменяли всё". А тут - тянет на обычный минорный релиз.
>> Тем более, что вас лично никто не "убеждает в том, что сделано правильно".
> Дело же не в этом. Дело в том, что то, что сделано,
> уже сделано, и миллионы разработчиков используют это таким, какое оно есть.
>> есть две модели развития - с параллельной поддержкой и без. Это вторая.
> Причем здесь модели разработки? если вам пишут что это два отдельных языка.
> Говорить о них как о чем то общем - неправильно. Поэтому
> нет никакого морального права называть PHP 7 именно PHP. Cronos же
> на назвала Vulkan пятым OpenGL'ом. Однако так было сделано, и теперь
> язык php 5.6 будет подвергаться гонению и искоренению, вместо развития.Точно так же как в свое время ПХП4 подвергся после появления ПХП 5, тогда тоже кричали что вы сделали с конструкторами? Клонированием? Что за странные private public protected? И это при том что тогда изменений было реально много и фундаментальных. А вот если в пхп 7 кодить в стиле пхп5.2 до сих пор возможно, то вам скорее всего даже ничего не прийдется переписывать, посыпятся депрекейты - отключите, если уж совсем лень.
А ты то пробовал? Там этих изменений с гулькин нос. Отвалился только модификатор е в регулярках, который сыпал варнингами начиная с 5.5, да пару извращённых конструкций, которые вообще стыдно показывать другим.
Я, исправив пару строк, запустил такой большой проект, как phpBBex, на 7 версии.
Ну для честности добавим, что между 5.2 или 5.3 или 5.3 или 5.4, не помню, перестал работать принудительный pass by reference, не описанный явно в аргументах, и принудительный return by reference. Тогда говнокода много поотваливалось.А так - да, исправлять много даже в этом говнокоде обычно не приходилось.
$foo->$bar['baz'] теперь интерпретируется как ($foo->$bar)['baz'], а не $foo->{$bar['baz']} - гореть им в аду за это
> $foo->$bar['baz'] теперь интерпретируется как ($foo->$bar)['baz'], а не $foo->{$bar['baz']}
> - гореть им в аду за этоВсплывает аналогия с sql и дефолтным приведением типов, может просто в следующий раз скобки сразу ставить?
никакой логики
Выдавшему такое - следует отрубать руки по самую задницу вне зависимости от языка. Превентивно и для экономии нервов окружающих.
В РНР использовать сколько-нибудь нетривиальные конструкции без скобок обычно отучает первый же вложенный тернарный оператор.
> В РНР использовать сколько-нибудь нетривиальные конструкции без скобок обычно отучает
> первый же вложенный тернарный оператор.В любом языке использовать нетривиальные конструкции без скобок - зло. За исключением случая, когда твой код, кроме тебя, никто читать не будет.
Молодцы, правильно у перла содрали
>Новый оператор "??",Мне вот интересно, почему они его как "||" не сделали?
Правильный аналог - //, но до него разрабы дорастут только лет через 10.
Вообще, отсутствие переменной логично было бы доверить разруливать оператору 0_0
>>Новый оператор "??",
> Мне вот интересно, почему они его как "||" не сделали?Потому что это оператор выполняет операцию "логическое или".
Перлу это не мешает, например. || -- "или", // -- "если левый операнд не определён". Операторы похожи, и выполняют примерно ту же функцию. Более того, там есть ещё "and" и "or", которые как раз и юзаются повсеместно в выражениях.Похапе: || + ??. "И хочется и колется", называется. ?? - воспринимается скорее как некая модификация тернарного оператора.
> Перлу это не мешает, например.И JavaScript-у - тоже не мешает.
> Похапе: || + ??. "И хочется и колется", называется. ?? - воспринимается
> скорее как некая модификация тернарного оператора.$x ?? $default и есть модификация тернарного оператора: isset($x) ? $x : $default;
"И ничего нет плохого!
Язык с ограниченными возможностями, бывает.
Не считать же теперь за недочеловеков тех, кто пишет на нём?"
> "И ничего нет плохого!
> Язык с ограниченными возможностями, бывает.
> Не считать же теперь за недочеловеков тех, кто пишет на нём?"судить о людях по языкам программирования может только тот, кто завис в развитии на уровне ниже амёб :)
О том и цитата :)
> судить о людях по языкам программирования может только тот, кто завис в развитии на уровне ниже амёб :)Это амёбы не могут судить. Уровень вхождения в языки очень варьируется. Не каждому дано освоить тот же с++, а вот на php пишут школьники. Язык с динамической типизацией и завалом говоманов в инете. Не надо знать что и как внутри устроено, уровень абстракции максимален, скопипастил и сиди, радуйся, страничка открывается.
Ох уж эти снобы. Когда perl был основным языком в веб на нем писали говнокод все подряд и не имели никаких проблем с "освоением". Точно также до появления жабы и шарпа все подряд строчили говнокод на плюсах или паскале. Так что "освоить" плюсы может столько же народу, сколько "освоить" пых. А знания внутреннего устройства может не быть и у тех, кто уверен в том, что он освоил язык-не-для-всех, выше есть замечательная иллюстрация на примере ассемблера.
Ну и мне приходилось видеть PHP код написанный хорошим плюсовиком - это было ужасно и тормозило дико. Ну не посчитал человек нужным вникать в пых и шпарил как на плюсах.
А знания внутреннего устройства может не быть и у тех, кто уверен в том, что он освоил язык-не-для-всех - как правило так и происходит(усердие поборовшее собственную ограниченность породило еще большую ограниченность, с целью больше так адово не усердствовать - инстинкт самосохранения). Те же сиплюсы по моему во всех вузах преподаются уже лет с десять(имею ввиду на соответствующих факультетах). А высокоуровневые языки на то и высокоуровневые, вот знаю я что в пыхе сессии хранятся на жестком диске а массивы в виде хеш таблиц, и что мне это дает? Аж ничего, нет смысла об этом заморачиваться, гораздо полезней подтянуть ООП синтаксис(благо тут есть что учить до конца дней), ПХП сам разберется какие свойства класса ему дублировать а какие нет. Программер должен заниматься программированием, а не быть разнорабочим, запиливая финты под определенную платформу.
Ваяют говнокод в процедурном стиле и самоутверждаются)
Адекватный человек с похапе быстро сбегает на что-то вменяемое. Умный видит это болото с бешеной конкуренцией со стороны студентов и индусов и заказчикам им под стать: "а вот здесь предлагают дешевле на 2 рубля" и вечно полыхающими сроками.
адекватный посмотрит на количество вакансий у похапе программистов и тип заданий на апворке.но можно конечно продолжать мечтать.
...и если чуть-чуть подумает - всё поймёт про уровень местной текучки персонала, взаимозаменяемость пыхокодеров, и их общий уровень, раз такая текучка возможна. И даже если пойдёт на одну из них - ему придётся поддерживать и расширять зоопарк кода, написанный пятью+ разными людьми до него. Оно ему надо?А ещё он может заметить однотипность заданий типа "прикрутить галерею к 100500му магазину на жумле", стабильно низкий требуемый уровень квалификации, требуемых для их выполнения и засилие "молодых, динамично развивающихся компаний" в заказчиках, которые существуют по полгода и которые могут тупо кинуть с оплатой.
Уж пятый год ищу куда сбежать, попутно выучил джаву и сиплюсы(благо они мало отличаются от пхп, по сравнению с тем же джаваскриптом, про ерланг вообще молчу), а вакансии все не появляются. Может посоветуете?
PHP – «50 оттенков серого»
"Внезапность и безысходность - две основные парадигмы кода на пхп".
Мне лично очень понравился чисто еврейский оператор <=>, буду его теперь везде использовать))) Лулзов ради.
> Мне лично очень понравился чисто еврейский оператор <=>, буду его теперь везде
> использовать))) Лулзов ради.На самом деле офигенный оператор. Превратит множество кастомных sort-функций в однострочники.
Пока не актуально, когда будет поддержка сабжа со стороны хостингов тогда - будем посмотреть.
> Пока не актуально, когда будет поддержка сабжа со стороны хостингов тогда -
> будем посмотреть.В чём проблема взять тот хостинг, который поддерживает?
>> Пока не актуально, когда будет поддержка сабжа со стороны хостингов тогда -
>> будем посмотреть.
> В чём проблема взять тот хостинг, который поддерживает?В том что почти все проекты уже запилены, и лежат на каких то хостингах(хотя это даже не проблема это просто факт) на некоторых из них еще и 5.6 нет. Хотя пощупать уже интересно, в домашних условиях обязательно скоро займусь этим сразу же как пхп7 включат в репозиторий Федоры(ну или хотябы в rpmfusion)
> (хотя это даже не проблема это просто факт)Именно. Есть хостинги с PHP 7.0, ничто, абсолютно ничто не мешает их использовать.
> на некоторых из них ещё и 5.6 нетНа некоторых и 5.5 нет, и 4.4 можно найти, это же не повод на них равняться))
Понятно что нет смысла равняться, но программированием для себя я не занимаюсь(а если и занимаюсь то только после того как 7ку включат в в мой десктопный дистриб), а те проекты в которых учавствую пока до 7ки не доросли, вот и говорю - прийдет время посмотрим(исключительно субъективное мнение).
Кое что все же мешает, например в том случае если это не платный хостинг а корпоративный и расположен у какого то клиента.
> Пока не актуально, когда будет поддержка сабжа со стороны хостингов тогда -
> будем посмотреть.Мы поддерживаем. В общедоступных спеках пока не опубликовали, но инстансы уже развёрнуты и готовы принять клиентов по запросу.