Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 95
PHP, ты порой умеешь удивлять…
К шестой версии таки подберутся по мощности функционала и качеству к питону и руби
Улучшение SSL/TLS, В OpenSSL добавлена функция проверки отпечатка пальца.fingerprints — это не совсем отпечаток пальца)
Интересно, почему многоточие, а не звёздочка, например.
Небольшая аргументация есть в одном из двух RFC, затрагивающих эту тему: wiki.php.net/rfc/variadics#choice_of_syntax
Не могу даже представить чем руководились, принимая такой синтаксис:
function f($req, $opt = null, ...$params) {
function f($req, $opt = null, ...$params) {
синтаксисом других языков?
На самом деле интересно. В Java тоже многоточие после имени типа, в Scala — звездочка после типа переменной, в питоне звездочка перед имененем переменной. Больше всего похоже на Java, т.к. типа в PHP нет (кроме подсказки имени класса).
В ruby тоже звездочка перед именем переменной, в Котлине — ключевое слово vararg, в Dart — нет встроенной поддержки (http://stackoverflow.com/questions/13731631/creating-function-with-variable-number-of-arguments-or-parameters-in-dart).
Си для PHP важнее, это же очевидно :)
А там как раз многоточие. Ну и значит мой комментарий был не совсем точен, так как первым делом пошел смотреть как все это устроено в Java и Си. в Scala, подумал, аналогично яве должно быть.
// Я больше не буду злоупотреблять смайликами в комментариях на «Хабре»
А там как раз многоточие. Ну и значит мой комментарий был не совсем точен, так как первым делом пошел смотреть как все это устроено в Java и Си. в Scala, подумал, аналогично яве должно быть.
// Я больше не буду злоупотреблять смайликами в комментариях на «Хабре»
«Духом PHP», очевидно. Неужели это первая синтаксическая особенность, которая вас смутила за время знакомства с PHP?
Ну в Си/Си++ такой синтаксис для списка аргументов, много где еще так же. А как бы вы хотели?
С трепетом вспоминаю как придумывал костыль для этого.
а где обещанные именованные параметры?
А кто обещал? Еще вроде бы обсуждают только: wiki.php.net/rfc/named_params
Я до сих пор не понял, почему каждый второй ноет про именованные параметры. Почему бы ассоциативный массив не передавать? Можете прояснить?
ну наверное потому что при таком подходе не работает автокомплит…
а без IDE программист уже не в состоянии программировать?
При всех недостатках IDE зачастую увеличивает скорость при сохранении качества.
Если есть инструмент хоть немного ускоряющий время разработки — то почему бы его не использовать? А при коммерческой разработке сокращение временных издержек это хорошо.
Я верно неправильно выразился. Я только обеими руками ЗА использование средств автоматизации, но программист должен что-то и ручками делать.
Ну бывает нужно код и в mcedit быстро подредактировать, это понятно. Но это не значит что нужно ориентироваться на такой тип разработки в целом и если есть возможность улучшить поддержку языка в IDE без каких либо потерь, почему бы этого не сделать. Без IDE вам все равно без разницы, будет тоже самое что и ассоциативный массив передавать (да и его вам использовать не запрещают), а тем кто пишет в IDE станет удобнее.
Мне казалось, что наоборот, — профессиональный говнокодер без IDE писать не состоянии. Мне например наоборот мешает, когда IDE за меня решает где ставить скобки и так далее. Понятно, что всё это можно настроить. Но лично я печатаю в слепую и довольно быстро, так что вот эта автоподстановка скобок и др. не сильно уж облегчают разработку, да и названия функций в PHP (я имею ввиду из коробки) не настолько длинные, чтобы каждый раз юзать автокомплит. Да и вообще названия функций не должны состоять более чем из трёх лексических единиц.
Наверно вы просто не хотите научиться всем функциям мощной IDE, например, PhpStorm — горячая клавиша Ctrl+N — поиск класса и сразу переход к файлу этого класса. Или Ctrl+F12 — навигация по методам класса и поиск методов. Все это очень удобно и позволяет сократить время для рутинных действий при разработке, обходиться вообще без мышки.
настройка coding style при работе в команде — это важно. Исключает варианты при которых какой-нибудь вася пупкин будет комитить изменения в каком-то своем coding style. Ваши же доводы по поводу «слепой печати» более чем странны, только если для вас при слепой печати вы не закрываете глаза или смотрите куда-то но не на монитор.
по поводу автокомплита — вы либо не использовали сторонние библиотеки/фреймворки, либо вообще имеете мало опыта в написании больших проектов. Автокомплит позволяет избавить разработчика от необходимости держать в голове всю api всех компонентов проекта. Ну и опять же есть где-то две трети функций самого php, к которым если и нужно обращаться, то довольно редко, и тут автокомплит позволяет быстро вспомнить что там где, и какие аргументы оно принимает. Это быстрый способ обращения к документации, если хотите.
по поводу автокомплита — вы либо не использовали сторонние библиотеки/фреймворки, либо вообще имеете мало опыта в написании больших проектов. Автокомплит позволяет избавить разработчика от необходимости держать в голове всю api всех компонентов проекта. Ну и опять же есть где-то две трети функций самого php, к которым если и нужно обращаться, то довольно редко, и тут автокомплит позволяет быстро вспомнить что там где, и какие аргументы оно принимает. Это быстрый способ обращения к документации, если хотите.
Потому что сктриктово.
Ну нельзя например type hint использовать
Потому что из объявления функции в этом случае не понятно, что туда можно передать.
Дэбагер надо будет посмотреть)
Как-то не впечатляют изменения, ожидал большего от 5.6…
А по-моему круто, что новые версии PHP стали выходить регулярно и довольно часто к тому же. Пусть изменений немного и они нереволюционные, зато на регулярной основе.
Загрузка файлов больше 2Гб
Интересно, а нормальное получение размеров больших файлов (больше 2/4Гб) на 32-битном PHP уже сделали или все так же придется продолжать писать всякие извращения для этого?
Совсем не по теме, но у меня уже восьмой год в голове стоит вопрос: зачем все имена переменных в этом языке включают знак доллара?
потому что без бакса — это не переменная, а константа
Наследие перла вероятно
Изначально, насколько я помню, это было связано с ограничениями парсера языка (по сути парсер представлял собой ворах регулярок). Сейчас вроде как это дело на нормальный парсер перенесли с разбором в AST (во всяком случае это как-то проскакивало в rfc). Ну и влияние perl-а.
На данном этапе убрать символ $ уже не получится, т.к. поломается сильно обратная совместимость — Константы, вызов функций и new через меременную:
И таких ситуаций очень много.
$func = 'cos';
$func(20);
func = 'cos';
func(20); // что вызывать? func - это name или переменная?
И таких ситуаций очень много.
А я даже причин не вижу, чтобы что-то убирать. Мне всегда в PHP это наоборот нравилось, что даже беглым взглядом видно, где переменные, глаз цепляется за $
А еще это символ доллара $)) Да в этом есть как плюсы, так и минусы, думаю их поровну.
Нормальные IDE умеют подсвечивать пересенные, даже если они не отмечены баксами. Но «блокнотам с подсветкой» так удобнее парсить, да.
А у вас не бывает ситуаций, когда вы код не в IDE смотрите, совсем никогда? Я вообще-то не про парсинг редакторами говорил, а про просмотр кода человеком, при чем совершенно независимо от того подсвечено там что-то или нет.
Если мне нужно понять код, а не просто посмотреть или скопипастить строчку, то открываю IDE. Анализировать код без IDE худо, потому что часто нужно разбирать множество файлов из разных папок. А чтобы скопипастить строчку из известного кода, не то что подсветка переменных не нужна, но и вообще подсветка.
вот ей богу проблема со знаком доллара у переменных у меня лично бывает только тогда, когда переключаешься на большой срок (пару месяцев) на другой какой язык (у меня так были периоды когда большую часть времени я писал на javascript, c++, c#)
Если бы они сделали Named Function Epression и Function Declaration как в JS, проблем бы не было, но обратная совместимость покатится к чертям.
Вообще идея переменная = свойство глобального объекта, а функция — его метод, сама по себе хороша и это доказывает множество языков. Если бы включили это в php, возможно, сам язык был бы привлекательнее.
Вообще идея переменная = свойство глобального объекта, а функция — его метод, сама по себе хороша и это доказывает множество языков. Если бы включили это в php, возможно, сам язык был бы привлекательнее.
И превратился бы в JS? По мне так PHP движется в сторону Java и Питона и поэтому это было бы не очень логично. Да и это бы превратило PHP в другой язык программирования.
И превратился бы в JS?
Почему же.
идея переменная = свойство глобального объекта, а функция — его метод
это как раз подход python, js и ruby.
я просто высказал мнение по поводу доллара. Мне кажется довольно таки правильным решением хранение функций внутри переменных сразу при объявлении и в python, кстати, переменные и функции без знаков.
PHP имеет ряд приятных особенностей, но синтаксис и ООП в нем пока выглядят худо.
Это бы было правильным решением, если бы писался новый язык. На счет того, что худо выглядит ООП, может быть, но думаю это больше относится к php 4 версии. По мне основные недостатки php не в языке, а в несогласованности его рантайм библиотек, в некоторой магии.
Возможно вам кажется синтаксис php не очень приятным из-за большого количества непрофессиональных разработчиков, которые программируют на нем.
Возможно вам кажется синтаксис php не очень приятным из-за большого количества непрофессиональных разработчиков, которые программируют на нем.
Возможно вам кажется синтаксис php не очень приятным из-за большого количества непрофессиональных разработчиков, которые программируют на нем.
Да нет, я тоже когда то был не ахти программистом и уж тем более php программистом (перешел на php с С++ и шарпа из за популярности на нашем рынке). И, если я сейчас сталкиваюсь (довольно часто) с некачественным кодом — я стараюсь уговорить заказчика дать задачу по улучшению и рефакторингу.
Рассуждая про синтаксис я имею ввиду символ конкатенации строк, символ обращения к методу или свойству (->) и работа с массивом (=>). Слава богу в 5,4 ввели шорт синтакс для массива в виде квадратных скобок (как в python / js).
На счет того, что худо выглядит ООП, может быть, но думаю это больше относится к php 4 версии
ООП выглядит худо до сих пор. Я имею ввиду не модель создания своих классов, так как функционал изрядно пополнился неймспейсами, миксинами и так далее, я говорю про общую ООПшность языка. Если посмотреть на те же python / js / ruby — у них нет простых типов данных. Все, так или иначе является объектом и имеет ряд методов для работы с этим объектом. В js так вообще функция может являться объектом, а в замыканиях может храниться функция-объект, которая при вызове func() — сделает одно действие, а при вызове func().exec() — другое.
Ну вот JS в качестве ООП-ного языка приводить не стоит. Прототипная модель очень спорная и даже Mozilla фактически это признала внедрив в новую версию языка классы. На счет ruby не знаю, на счет Python не уверен — если там до сих пор нет private и protected модификаторов, все сводится к фанатичным обсуждениям что это «не нужно», в JS их собственно пока тоже нет.
Все является объектом хорошо, но в JS это правило до конца не соблюдается как надо. Однако же я не сторонник перегрузки операторов для объектов, а если все объект их придется вводить.
Все является объектом хорошо, но в JS это правило до конца не соблюдается как надо. Однако же я не сторонник перегрузки операторов для объектов, а если все объект их придется вводить.
Неоднородность синтаксиса это наследие былых лет, тут уж ничего не поделать. По сути серьезно воспринимать php можно только с 5.3+ версий.
По поводу ООП — там нету миксинов, там есть только трейты (в objective-c это называется категориями). По поводу того что есть скалярные типы данных, не могу сказать что это так уж и плохо. И прототипную модель наследования из js вы так же за зря приплели. Тут вы путаете концепцию наследования всех типов от object (например как это сделано в C#, где все типы наследуются от System.object). В python свои косяки с реализацией ООП оставшиеся с ранних версий (я про отсутствие модификаторов private/protected, явное указание контекста вызова через self и т.д. Не могу сказать что это такой уж идеал.).
как я уже говорил, большая часть проблем php — наследие былых времен. Решение использовать этот инструмент или нет — это только ваше решение. Не нравится — альтернативы есть. Недостатки есть везде, плохих программистов хватает на любой платформе, так что дискуссии на тему «что лучше» бессмысленны.
По поводу ООП — там нету миксинов, там есть только трейты (в objective-c это называется категориями). По поводу того что есть скалярные типы данных, не могу сказать что это так уж и плохо. И прототипную модель наследования из js вы так же за зря приплели. Тут вы путаете концепцию наследования всех типов от object (например как это сделано в C#, где все типы наследуются от System.object). В python свои косяки с реализацией ООП оставшиеся с ранних версий (я про отсутствие модификаторов private/protected, явное указание контекста вызова через self и т.д. Не могу сказать что это такой уж идеал.).
как я уже говорил, большая часть проблем php — наследие былых времен. Решение использовать этот инструмент или нет — это только ваше решение. Не нравится — альтернативы есть. Недостатки есть везде, плохих программистов хватает на любой платформе, так что дискуссии на тему «что лучше» бессмысленны.
> В python свои косяки с реализацией ООП оставшиеся с ранних версий (я про отсутствие модификаторов private/protected, явное указание контекста вызова через self и т.д.
И явный self, и отсутствие private — это вполне себе by design, а не просто наследие старых версий.
И явный self, и отсутствие private — это вполне себе by design, а не просто наследие старых версий.
По сути серьезно воспринимать php можно только с 5.3+ версий.
После 4, 5 тоже был очень хорош, проблема же была в том что после 5.2 развитие по сути остановилось на 4 года.
Это подход Ruby и JS, но не Python. В последнем переменные (функции и классы — это тоже переменные) становятся атрибутами объекта модуля, в котором они декларированы, что не совсем то же самое.
Кто вам мешает реализовать свой язык программирования?
еще один noname язык? лучше написать фреймворк над языком, да и на это нет времени. В данный момент я занят выбором инструмента для создания своих проектов (не от заказчиков) и PHP пока лучший кандидат в соотношении цена / качество / временные издержки. Но по завершении наверняка буду переводить проекты на python.
На js вон добровольно переменные, содержащие jquery-объекты, предваряют знаком доллара, а вам не нравится :))
Еще больше хаоса в PHP, полезного и нужного!
Ура, вместо так необходимого php прямого управления памятью(чтобы делать ад php наполненный демонами) — мы получили снтакическую какашку из 100500 use, которая работает примерно также как перпроцессор в C, только это не он а лишь эмуляция!
Ура товарищи! Вперед к светлому будущему!
Ура, вместо так необходимого php прямого управления памятью(чтобы делать ад php наполненный демонами) — мы получили снтакическую какашку из 100500 use, которая работает примерно также как перпроцессор в C, только это не он а лишь эмуляция!
Ура товарищи! Вперед к светлому будущему!
А почему в обзоре упущена часть изменений, в том числе с deprecated нововведениями?
Хорошие нововведения, молодцы!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP 5.6.0 alpha1