Что может измениться в php 5.5 (англ.)

[fixxxer]

флоппик
И получишь неочевидные проблемы после замены
function ($a, $b, $c = null)
на
function ($a, $b, $c = null, $extra_optional_paramerer = null)


вообще это все поощрение говнокода. больше 5 параметров у функции быть не должно. если становится больше, надо выделять в класс с fluent-интерфейсом.

 

[флоппик]

вообще это все поощрение говнокода. больше 5 параметров у функции быть не должно. если становится больше, надо выделять в класс с fluent-интерфейсом.

Согласен, да Мне вообще вроде такое никогда было особо не надо.

 

[Absinthe]

Полезно для заворачивания опций, чтобы не чейнить параметры.

 

[fixxxer]

Если параметры по свой сути опциональные и их пачка, то передавай key-value массив: наверняка в таком случае внутри функции все равно массив строится.
Если они не связаны, то функция неминуемо распухает на 5 экранов со свитчами и ифами - а это уже признак того, что необходимо выделение в класс; тут чейнить или по-другому строить API - это уже зависит от.

 

[A1x]

вот чего бы мне хотелось:
- автолоад для функций (по аналогии с таковым для классов)
- аналог __get и __set для обычных переменных (не переменных класса)

 

[Sufir]

- аналог __get и __set для обычных переменных (не переменных класса)

Зачем, если не секрет?!

 

[A1x]

например для автоэскейпинга в шаблонах... хотя не уверен что это было бы хорошо

echo $var; // заэскейпленный вариант по умолчанию

echo $_var; // raw

 

[A1x]

еще очень неудобно постоянно таскать $this-> внутри методов для обращения к переменным и методам этого же класса

 

[Ragazzo]

A1x
не стоит тащить то, что "удобно" в процедурном стиле в ООП

 

[A1x]

Ragazzo если ты про $this-> то ну вообще то в чисто оопшной яве так и сделано, что this можно не писать каждый раз

в пхп приложении есть чисто код (контроллеры, модели, етс.) и есть шаблоны, и если в коде более удобно ООП
то шаблоны имхо тяготеют к процедурному стилю. Взять например модификаторы переменных, за которые мы так любим смарти и прочие шаблонизаторы.
почему бы не сделать их частью языка?
Может быть вообще сделать два режима компилятора - один для чисто кода, другой для шаблонов

 

[Вурдалак]

еще очень неудобно постоянно таскать $this-> внутри методов для обращения к переменным и методам этого же класса

Ну так это потому что в PHP есть функции и глобальные переменные, появляется неоднозначность.

 

[~WR~]

Вряд ли кто-то поддержит, но я в первую очередь смотрю на радикально новые фичи.
Когда появляется что-то такое, чего раньше было сделать нельзя, а теперь - можно.

Например, вспомните, сколько всего появилось в 5.3.
А тут таких фич нет - один лишь синтаксический сахар. Апдейт бесполезен, php в тупике.

 

[grigori]

> не столько хинтинг, сколько приведение к нужному типу - т.е., короткая запись для function ($id) { $id = (int) $id; ... }
именно приведение, затраты на него, Размус назвал причиной, почему он против тайпхинтинга

> copy-paste c C#. Хуже не будет.
на подобные аргументы я помню ответы вроде "we don't want to make another [name] language"
объектная модель php следует за java, а не за c#, неочевидно использование этого синтаксиса в php,
хотя, хрен знает, что им там придет в голову

>Для консистентности языка. Никогда не получал проблем при рефакторинге с заменой empty($var) на empty($this->getVar()) ?
ну, ради консистентности может и прокатит, а рефакторинг надо делать не на "empty($this->getVar())", а просто на "$this->getVar()", и все

~WR~ не php в тупике, просто автор статьи, вчерашний школьник, развел холивар на весь мир

 

[Absinthe]

Если параметры по свой сути опциональные и их пачка, то передавай key-value массив

Способ плохой, т.к. IDE не умеет подсказывать варианты и придется держать документацию открытой.
Чейнинг тоже способ не очень, т.к. надо писать дополнительный код в классе, который потом чейнить.
Питоновский подход с именованными параметрами спасет от обоих недостатков.

 

[Вурдалак]

> не столько хинтинг, сколько приведение к нужному типу - т.е., короткая запись для function ($id) { $id = (int) $id; ... }
именно приведение, затраты на него, Размус назвал причиной, почему он против тайпхинтинга

Очевидно же, что не будет никаких затрат, если тип переменной будет совпадать с текущим, а это в большинстве случаев. В противном случае — плохой интерфейс.

 

[A1x]

Ну так это потому что в PHP есть функции и глобальные переменные, появляется неоднозначность.

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

 

[grigori]

Вурдалак, 1. я не PR-менеджер Размуса, я цитирую его ответ на мой вопрос
2. если тебя интересуют детали, аргументация была такая: в http и в базе вся информация идет в строке, а приведение чаще всего необязательно, но с тайпхинтами его будут писать везде просто так, и вреда миру от этого будет больше, чем пользы

на самом деле приведение чаще всего будет из строки в int, и php в 99% случаев имеет дело с joomla, drupal, реальным низкокачественным кодом, а не с нашими хорошими интерфейсами

 

[Вурдалак]

1. я не PR-менеджер Размуса, я цитирую его ответ на мой вопрос

А я комментирую его ответ, расслабься.

 

[Redjik]

grigori
так я не понял - приведение строки к (int) - это хорошо или плохо?

я частенько привожу к int, несмотря на препареды, если мне нужно по айдишнику вытащить что-либо...

 

[grigori]

Redjik ты спрашиваешь мое мнение или Размуса?