Для включения в состав будущей ветки PHP 7 одобрена (http://marc.info/?l=php-internals&m=142653986312803&w=2) возможность явного определения (https://wiki.php.net/rfc/scalar_type_hints_v5) скалярных типов int, float, string и bool для аргументов и значений функций (например, "function foo(int $abc)"). Кроме того, будет добавлен новый режим жесткой проверки типов, включаемый директивой "declare(strict_types=1)", при котором несоответствие типа передаваемого функции или возвращаемого функцией значения будет приводить к ошибке. Поддержка режима проверки типов будет добавлена в том числе для расширений и встроенных функций PHP.URL: http://marc.info/?l=php-internals&m=142653986312803&w=2
Новость: http://www.opennet.me/opennews/art.shtml?num=41858
А такой тип данных, как указатели, появится в этой версии пхп?!
Наверно появится, но не один пыхпыхер никогда не будет им пользоваться.
Тс-с-с-ссОни решили пойти по пути питонистов и наплодить несовместимые ошметки.
Скорее, производительность HHVM им покоя не дает. Мордокнига уже теснит пыхпыха. Они то знают как это делать правильно.
А ничего так что hhvm разрабатывают те-же кто разрабатывал zend engine? Например Давид Бергман или Сара Големан. Правда я не в курсе учавствует ли Никита Попов в hhvm или он только в ZE.
Они вовремя съе... в фэйсбук? :)
Указатели вряд ли. Думаю в масштабе ПХП 90% применений указателей будут перекрываться передачей параметра по ссылке (а это, наверное, уже и так есть).
вы там совсем одурели с php? какое передача по ссылке, это VM а не сишный код.
А какое отношение "передача параметра по ссылке/значению" имеет к "VM/native"?
ну шо вы к человеку пристали, он совсем не в программиских темах :)
Зачем в PHP ЭТО ?
Вот расскажите нам, ЗАЧЕМ смешивать быка и носорога, всандаливая в решения для Web приложений такие вещи ?
передача по ссылке решает весь спектр задач в рамках применения стандартных паттернов.
И толпа быдлокодеров не выстрелит себе в ногу ...
А попытка писать на PHP вещи, которые на нем писать ну никак нельзя ... так это признак "сам себе злобный буратино"
> И толпа быдлoкодеров не выстрелит себе в ногу ...Напротив, при отсутствии типизации можно сравнивать или делать операции с совершенно разными сущностями. Что ведет к дурным логическим ошибкам, которые можно было бы отловить заранее. Но не отловили.
>> И толпа быдлoкодеров не выстрелит себе в ногу ...
> Напротив, при отсутствии типизацииНельзя говорить "отсутствии типизации".
Есть языки с "динамической типизаций", к каковым относится PHP.
Второе - с какой радости Вы привязываете указатели к стат. типизации - не понятно.
Вот Java - там стат. типизация, но указателей нет, даже близко> Что ведет к дурным логическим ошибкам, которые можно было бы отловить заранее.
Тут нельзя не согласиться, но большая часть языков для Web как имеет дин. типизацию.
> Нельзя говорить "отсутствии типизации".Можно. Когда речь идет о ассемблере, форте и/или BCPL.
> Есть языки с "динамической типизаций", к каковым относится PHP.И вот эта динамическая типизация имеет свойство оказывать медвежью услугу.
С одной стороны динамическая типизация ставит крест на какой либо производительности, поскольку вместо простейшей операции (в лучшем случае просто регистр-регистр проца для математики и логических операций) - получается целый огород из множества проверок "а какой у нас тип теперь?". Там куча действий и скорость в зависимости от того где это может провалиться и в хренадцать раз при прочих равных. Поэтому даже в JS с горя типизированные массивы сделали, в попытках хоть как-то это замахать. Толку правда хрен, потому что костыли и полумеры.
С другой стороны, динамическая типизация просто поменяет тип, даже когда имеет мсто явно ошибочное действие. По поводу чего дальнейшее содержимое переменных может оказаться весьма неожиданным для остальной логике. То что это приведет к куче багов и даже проблем безопасности - как пить дать.
> Второе - с какой радости Вы привязываете указатели к стат. типизации - не понятно.
Я? Указатели? Я вроде про них ничего не говорил.
> Тут нельзя не согласиться, но большая часть языков для Web как имеет
> дин. типизацию.О чем немало сожалеют те, кого угораздило сделать проект покрупнее...
Надо же, я вижу "с одной стороны", и "с другой стороны", и оба абзаца с текстом содержат критику динамической типизации.Ну во-первых, "с одной стороны" - верно только в совсем запущенных случаях. Вон тот же CL хоть и динамически типизирован, но для повышения производительности позволяет явно указать тип параметра в методе.
Во-вторых, "с другой стороны". Динамическая типизация и неявное преобразование типов - не одно и то же. Типизация динамическая, это когда один и тот же символ может быть связан в разные моменты времени со значениями разных типов. Преобразование типа к нужному при вызове процедуры тут, вообще говоря, не при чём.
Основным минусом динамической типизации является то, что ошибки типа отлавливаются только в runtime. То есть в случае со статической типизацией, Вы получаете жирную ошибку во время компиляции о том, что типы не сошлись. А в случае с динамической Вы получите эту же ошибку только во время работы программы. Вот это действительно Причина недовольства динамической типизацией. Это налагает большую ответственность на разработчика.
Основной плюс динамической типизации заключается в удобстве разработки: Вам не нужно договариваться с компилятором о соответствии типов, и убеждать его, что никакого конфликта тут нет. Вот допустим, ваша функция сортирует массив элементов какого-нибудь типа. В строго типизированном языке Вам придётся описывать свою функцию для сортировки массива каждого типа, а в динамическом Вы опишите функцию сортировки в целом, и она будет ещё иметь параметром функцию сравнения двух элементов.
Именно последнего плюса динамической типизации и пытаются достичь строго типизированные языки: вспомните хотя бы эту попытку C++ ввести шаблоны, ну или систему вывода типов в Haskell/ML/OCaml.
Если уж наезжаете на динамическую типизацию - так хоть говорите по существу.
> В строго типизированном языке Вам придётся описывать свою функцию для сортировки массива каждого типа, а в динамическом Вы опишите функцию сортировки в целом, и она будет ещё иметь параметром функцию сравнения двух элементов.Java и C# смотрят на вас с недоумением.
>> В строго типизированном языке Вам придётся описывать свою функцию для сортировки массива каждого типа, а в динамическом Вы опишите функцию сортировки в целом, и она будет ещё иметь параметром функцию сравнения двух элементов.
> Java и C# смотрят на вас с недоумением.Потому что в строгия языках для удобства вводят фишки слабых, а в слабых - фишки строгих.
Вот в том же Си вы небось void можете в качестве заглушки использовать, не так ли?
java.util.Arrayspublic static <T> void sort(T[] a, Comparator<? super T> c)
java.util.Collections
public static <T> void sort(List<T> list, Comparator<? super T> c)
Тип T выводится во время компиляции. Такие дела.
Дочитать до конца, видимо, не судьба была.
До конца чего? Или в действительно считаете, что Type Erasure это фишка из динамических языков?
> До конца чего?Комментарев #87 и #89...
> Или в действительно считаете, что Type Erasure это фишка из динамических языков?
...чтобы не задавать таких глупых вопросов.
А то уже надоело: Сначала прочитают через строчку, потом надумают себе море глупостей, и начинают опровергать их в ответах на оригинальный пост.
>решает весь спектр задач в рамках применения стандартных паттернов.Ну если сначала себя ограничить уже имеющимися практиками, то ничего нового действительно не нужно, ведь текущие практики работают и без этого.
А так вообще пыху бы не помешали нормальные ссылки, вместо их текущего кастрированого варианта. С другой стороны, если перечислить все, что нужно пыху, чтобы стать нормальным языком, то там и к десятой версии всего не сделают.
>>решает весь спектр задач в рамках применения стандартных паттернов.
> Ну если сначала себя ограничить уже имеющимися практиками, то ничего нового действительно
> не нужно, ведь текущие практики работают и без этого.Прочтите еще раз о чем писал я, начиная с фразы:
"передача по ссылке решает весь спектр задач в рамках применения стандартных паттернов. "
Я ведь вел речь о том, с какой радости дону нужны указатели в PHP когда полноценные ссылки и построенные на них паттерны все решают ... а Вы взялись мне прописные истины излагать.
В пыхе нет полноценных ссылок.$a=array(1,2);
$c=array(&$a,3);
$d=$c[0]; //ключевой момент
$c[0][1]=4;
$d[1]=5;
var_dump($a); //выдаст 4
> В пыхе нет полноценных ссылок.
> $a=array(1,2);
> $c=array(&$a,3);
> $d=$c[0]; //ключевой момент
> $c[0][1]=4;
> $d[1]=5;
> var_dump($a); //выдаст 4Вообще-то в массиве $a в ячейке 1 будет 4, содержимое 0-й останется 1, это мелкая неточность
В целом же еще раз не понимаю к чему Вы боретесь с ветряными мельницами и рассказываете всем известные очевидные вещи.
$d = &$c[0]; //ключевой моментЭто как раз и есть ссылка. Просто в перле, например, ссылка - это скорее указатель, а не ссылка. А то, что в пыхе - это как раз ссылка.
выдаст то оно выдаст, только здесь в каждой строке ссылка (на zval), если что :)
Непонятно только, зачем превращать пых в какой-то "нормальный язык". Этих "нормальных" уже достаточно, если вам действительно нужны преимущества, которые дают Питон, Руби, С++ или Жаба, так ими и пользуйтесь... кто ж мешает-то?
У Пыха, конечно, море недостатков. Но их исправление по-перфекционистски устранит два его главных достоинства: снисходительность к программисту и низкий порог вхождения.
Хотите, чтобы море пыхеров не писало быдлокод? Дайте им удобные, производительные и популярные фремворки, которые не позволят этого делать, и проблема исчезнет сама собой... А любые другие пути решения этой проблемы - заведомо тупиковые.
> Но их исправление по-перфекционистски устранит два его главных достоинства: снисходительность к программисту и низкий порог вхождения.Это не достоинства, это вас кто-то обманул.
Увы, именно эти "не достоинства" обеспечили ему лидерство в веб-разработке.
"Это как демократические выборы - большинство всегда за сволочь", sad but true.
> Увы, именно эти "не достоинства" обеспечили ему лидерство в веб-разработке.мда... из серии "достоинства javascript обеспечили ему лидерство в клиентской веб-разработке".
> Это как демократические выборы - большинство всегда за сволочь
именно, это как демократические выборы - когда выбора нет вообще, как класса :)
> именно, это как демократические выборы - когда выбора нет вообще, как класса :)и с каких пор у тебя нет выбора, на чём писать бэкенд?
> мда... из серии "достоинства javascript обеспечили ему лидерство в клиентской веб-разработке".Внезапно, да. Повсеместная распространенность - это достоинство. Причем настолько важное, что перекрывает любые недостатки, как мы видим.
Эти "не достоинства" обеспечили ему лидерство в те времена, когда веб-разработка не имела вообще ничего с общего с нынешней. А ещё важнее было то, что в те времена, когда он стал популярен, альтернативой был лишь Перл - который для веба был весьма неудобен со своим модулем CGI и отсутствием всех мыслимых батареек из коробки. Ну и то, что PHP работал без особых чудес через mod_php, в то время как mod_perl требовал некоторого понимания архитектуры как перла, так и апача с его модулями.
Но сейчас-то появились нормальные языки и все изменилось, правда?
Именно. От JS в современном виде до Go. В результате новые проекты на PHP как минимум вокруг меня стараются не начинать. А поможет ли это неспешное местное исправление косяков (отсутствия) дизайна - поглядим. Хотя типизация - это очень и очень хорошо, избавляет от массы проблем в поддержке.
Тогда, пожалуйста, просто перечислите CMS и фреймворки, на который начинают новые проекты вокруг вас. Мы же о работе, а не о велосипедах? Думаю, многим интересно.Типизация - это прекрасно, кто бы спорил. Вопрос только в том, получит ли новый рогатый жираф какое-то реальное преимущество перед безрогими. Или так и останется теоретически прекрасным.
Честно говоря, понятия не имею. Языки знаю - питон, джава, немного JS, сейчас одни на Go пробуют. Но это всё крупные проекты, даже если не энтерпрайз - то стартапы с жирным финансированием.А что PHP одна типизация не спасёт - кто бы спорил. Адски неконсистентный язык.
присоединяюсь к вопросу, перечислите CMS и фреймворки
mojolicous
Я и так пользуюсь нормальным языком. Но недавно понадобилось немного на пыхе пописать. Это было кошмарно. Большую часть времени потратил на то, чтобы убедится, что в нем действительно нет ряда фишек, привычных по другим языкам. Даже javascript на его фоне кажется хорошим языком, неудивительно, что node.js стремительно отжирает долю пыха.
> Я и так пользуюсь нормальным языком. Но недавно понадобилось немного на пыхе
> пописать. Это было кошмарно. Большую часть времени потратил на то, чтобы
> убедится, что в нем действительно нет ряда фишек, привычных по другим
> языкам. Даже javascript на его фоне кажется хорошим языком, неудивительно, что
> node.js стремительно отжирает долю пыха.яких фишек? :-)
> Я и так пользуюсь нормальным языком. Но недавно понадобилось немного на пыхе пописатьА я десять лет пользовался С++, а потом пришлось много пописать на пыхе.
У обоих языков есть свои плюсы и свои недостатки, просто не надо пытаться закручивать гвозди стамеской.
>>У обоих языков есть свои плюсы и свои недостатки...У С++ точно есть два плюса)))
Он вам зачем?
Ура! Ждал этого до появления hhvm. Радует что конкуренция подогревает развитие.
php7 будет лучше hhvm.
И только на ...й год Соколиный глаз понял, что без одной стены холодно.
>PHP 7Именно 7?
Не 5.7, не 6, выпуска которого уже лет 6 ждут, а именно 7?
Вот скажите почему я, который активно на PHP не разрабатываю знаю что версии PHP6 не будет никогда и след. релиз будет 7-м ?Почитайте:
https://wiki.php.net/rfc/php6
http://habrahabr.ru/post/231605/
Спасибо за ссылки :-)
Скорее всего потому, что Вы активно читаете новости и на других ресурсах, а Я активно занимаюсь разработкой и в перерывах читаю новости по открытым IT-технологиям только здесь.
> а Я активно занимаюсь разработкой и в перерывах читаю новости по
> открытым IT-технологиям только здесь.Я тоже активный разработчик.
Чтение и изучение новостей занимает 15-25 мин. в день.
Просто у меня правильно подобранный набор RSS лент, когда ключевая информация из всех отраслей не замыливается хламом "вышел Н+1-е надкушенное яблоко"
Типизация то какая? судя по всему если они впиливают статическую типизация то она явно мягкой не будет.
Поздно пить боржоми, перешел на golang.
PHP 7 все еще тот же монстр UTF-8 (нативного нету через пару костылей/модулей) в отличии от хипстерского Go или нового стандарта Cpp11/Cpp14/Cpp18http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n244...
> PHP 7 все еще тот же монстр UTF-8 (нативного нету через пару
> костылей/модулей) в отличии от хипстерского Go или нового стандарта Cpp11/Cpp14/Cpp18callWinApiAsExample(u8"Прям-таки нативно, правда?!");
Будет натив, но уже лучше! В PHP полные костыли.. mbstring/iconv/ICU...- http://php.net/manual/en/mbstring.overload.php
- http://php.net/manual/ru/ini.core.php#ini.zend.multibyte
> Будет натив, но уже лучше! В PHP полные костыли.. mbstring/iconv/ICU...
> - http://php.net/manual/en/mbstring.overload.php
> - http://php.net/manual/ru/ini.core.php#ini.zend.multibyteДа что вам дался этот нативный утф? Это же с бинарными строками создаёт дикий геморрой, вон например как в JS. Или в Perl'е, где случайно флаг UTF-8 не включишь и хренак, двойной утф сразу...
В пыхе ЕДИНСТВЕННОЕ, чего не хватает - это mb_strcmp. А нативно или mb_ - какая нафиг разница?
> или нового стандарта Cpp11/Cpp14/Cpp18это там где комитет фичами новых стандартов тупо стебётся над разработчиками? -)))
Э... почему стебётся? Как минимум, в 11 и 14 отличные фичи. И добавить их в реализации оказалось легче, чем шаблоны, к примеру.
Ну потому что надо было уже стопицот раз реализовать модули вместо .hpp/.cpp, чтобы компиляция за адекватное время происходила, а они вместо этого добавляют всё больше и больше вариантов синтаксических конструкций, да похитрожопее, похитрожопее))Хотя конечно выведение типов-то да, приятно.
Но время компиляции просто убивает... а потом яву какую-нибудь собираешь - Compiling 158 source files... Build finished in 3 seconds.
Precompiled headers спасают. А так - ну не сумели они сделать систему модулей без потери обратной совместимости. Что для плюсов, разумеется, критично, учитывая адовую массу существующего кода.
В языках со строгой типизацией потихоньку привыкают к автоматическому выводу типов... а в PHP типы наконец-то можно указывать! Так держать!
> В языках со строгой типизацией потихоньку привыкают к автоматическому выводу типов... а
> в PHP типы наконец-то можно указывать! Так держать!Это потому что существуют те кто критикует PHP за не строгую типизацию. Ну разработчики решили а давайте угодим всем. А вообще строгая типизация повысит производительность PHP сценариев
> В языках со строгой типизацией потихоньку привыкают к автоматическому выводу типов...Ну т.е. всех таки уже задолбало эти типы указывать, да?
Так фишка в том, что от них избавились только там, где они не нужны, оставив всю статическую типизацию на месте. И даже там, где auto - IDE может показать, какой тип. Для подержки - безценно.
Наконеец-то лучик разума. От этой динамической типизации толку ноль, а уж сколько багов феерических несёт она в себе!
> Наконеец-то лучик разума. От этой динамической типизации толку ноль, а уж сколько
> багов феерических несёт она в себе!О, </да!> http://www.artima.com/weblogs/viewpost.jsp?thread=4639
Ну да, бывает. Ещё один человек, который не понял, что статическая типизация - это не только о быстром отлове ошибок (и возможности писать в разы меньше тестов, которые всё равно не покроют всё, что можно запихать в переменную), а прежде всего о чёткой архитектуре. С ней вариант "засунем в функцию что попало, а дальше разберёмся" (который так любят в JS) не проходит. Плюс явно указанные (или хотя выведенные и показанные IDE) типы - сами по себе отличная документация, сильно помогающая в поддержке. Но в мелких программках, которые не поддерживаются вообще или поддерживаются только их автором этого не видно - и поэтому вариант "попробовал писать на питоне и всё прекрасно получилось" совершенно не показателен.
> а прежде всего о чёткой архитектуреОй не надо. Зато больше времени тратится на всякую инфраструктурную муть (читай-типы) и меньше остаётся на само приложение))
You have a problem and decide to use Java. Now you have Problem, ProblemImpl, ProblemException and ProblemFactory?
А в плюсах так нудить, как в Джаве, отнюдь не обязательно. Ну и в большом проекте две трети этих абстракций - таки необходимость.После какого-то размера есть ровно две альтернативы - либо у нас есть "инфраструктурная муть" либо проект просто не может дальше шевелиться. За деталями - например, к лекциям Левенчука по системной инженерии - там хоть и из немного другой области, но объяснено отлично.
> А в плюсах так нудить, как в Джаве, отнюдь не обязательно. Ну
> и в большом проекте две трети этих абстракций - таки необходимость.
> После какого-то размера есть ровно две альтернативы - либо у нас есть
> "инфраструктурная муть" либо проект просто не может дальше шевелиться. За деталями
> - например, к лекциям Левенчука по системной инженерии - там хоть
> и из немного другой области, но объяснено отлично.Ты различия понимаешь между системным программированием и прикладным? Похоже что нет.
А вы пробовали в прикладном программировании сделать что-то сложнее пары форм, наваянных мышкой? Там, где начинают применяться паттерны и ООП во весь рост, поневоле приходится возводить абстракции над кодом, иначе сам перестаешь в нем что-либо понимать.
Да ты че? чето на винапи норм ваял и без мышки в свое время, и без всякого ооп
Читаю комментарии и понимаю, что большинство вообще не в курсе вопроса про типизацию, какое позорище а еще программисты.
Нету никакой типизации в принципе, это обман и ширма высокоуровневых языков. И программисты в отличие от тебя это знают.
Я просто рыдаю, пинком вас из профессии нужно пнуть чтоб летели и не вернулись.
mov eax, [ebx]Какой тип данных в EAX?
Ровно на том же основании можно столь же обоснованно заявлять, что кодировок тоже не существует, это обман и бНОПНЯ.
> Ровно на том же основании можно столь же обоснованно заявлять, что кодировок
> тоже не существует, это обман и бНОПНЯ.Ложки не существует
поздно пытаться сделать из говоноязыка конфетку