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

[AmdY]

приведение атрибутов методов было бы классной фичей, одной из лучших со времён filter_var. а то в коде довольно часто приходится делать руками.

 

[Dreammaker]

несмотря на препареды.

которые не всегда можно задействовать. Например, PDO со SphinxQL или наоборот SphinxQL c PDO, толком и не понял кто из них виноват, так и не захотели работать. Пришлось писать свою обертку с приведениями и прочими подобными штуками.

Ну или, например, MongoDB жутко параноидально относится к поиску по полю с целыми значениями, пхп же часто строку подсовывает. Приходится приводить к int.

 

[Chushkin]

Всё это хорошо конечно, хоть некоторое через одно место.
Но всё это вторично - на первое место по важности я бы поставил нечуствительность к регистру всех меток, в т.ч. и ключей в массивах. (вкл/выкл через ini_set, например)
При использовании горбатого метода заметно сократит время разраба на отлавливании ошибок из-за регистра и на рефакторинге старого кода.
(дефакто - во всё большем и большем числе проектов используется горбатый формат, а в БД вообще "стандарт")

 

[Chushkin]

приведение атрибутов методов было бы классной фичей, одной из лучших со времён filter_var. а то в коде довольно часто приходится делать руками.

Ещё лучше фиксированный тип.
Например, хотелось бы такую возможность:

public $var int read_only

или что-то в этом роде.
Как там внутри будет - по барабану. А в моём коде это всегда целое и при попытке присвоить значение отличное от целого выдавать предупреждение или ошибку (в зависимости от настроек).
IMHO, строгая типизация в классах как правило благо.

 

[Chushkin]

Разве есть какие-то принципальные препятствия для:

create_query("deleted=0", "name", , , false);

Согласен, - это правильный вариант.
А "default" это порнография

 

[Вурдалак]

Но всё это вторично - на первое место по важности я бы поставил нечуствительность к регистру всех меток, в т.ч. и ключей в массивах. (вкл/выкл через ini_set, например)

Потрясающая идея, учитывая, что 2 разных библиотеки могут быть написаны под разные режимы, соответственно какая-то из них будет тупо ломаться.

А вообще, все любители регистронезависимости в коде идут в жопу, старая тема, потому что оставляя в коде переменные в разном регистре, ты только оставляешь за собой грязь, а за собой надо убираться, мы же люди, а не голуби на деревьях.

Как там внутри будет - по барабану. А в моём коде это всегда целое и при попытке присвоить значение отличное от целого выдавать предупреждение или ошибку (в зависимости от настроек).
IMHO, строгая типизация в классах как правило благо.

Всё это, конечно, замечательно, только причём тут PHP? Пиши на Java.

 

[AmdY]

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

 

[Chushkin]

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

Тут дело не в том, что "у функций не должно быть больше двух параметров", как пишут в некоторых "умных" книгах. Тут спора нет - всё хорошо что в меру.
Другое дело, что если есть возможность пропуска параметров, то это должно быть максимально удобно для пользователя. (кстати, ПХП сильно отстаёт в этом - то, к чему только приходит, в других языках уже лет 10-15, а то и больше, используется)
И С. указал максимально правильный вариант - более лучших я не встречал. В частности, именованные параметры - понаблюдайте за собой, когда вы пишете функцию вы помните имена параметров или их порядок, что где писать. Хотя, как вариант, вполне допустимо - что мешает сделать и тот и тот вариант? Ничего. Точно также ничего не мешает сделать строгую типизацию и регистронечуствительность, а уж будут этим пользоваться разрабы или нет - дело личное. Я буду.
п.с.
Когда писал на Кларионе, я как-то привык, что при разработке думаю о задаче, а не о том, какой регистр буквы у параметра или какой тип у него - транслятор проконтролирует и ругнётся, если непорядок.
А тут, - ошибся в буковке и поди потом найди в десятках тысяч строк кода, где буковка не того регистра. Особенно в массивах...
Или забыл привести значение к нужному типу - тоже не 5 секунд найти где и понять почему не сделал.
В общем, всё это не просто гнутьё пальцев - в конечном счёте это экономия времени, которое стоит денег, как известно ... особенно заказчикам и работодателям

 

[Chushkin]

Потрясающая идея, учитывая, что 2 разных библиотеки могут быть написаны под разные режимы, соответственно какая-то из них будет тупо ломаться.

А вообще, все любители регистронезависимости в коде идут в жопу, старая тема, потому что оставляя в коде переменные в разном регистре, ты только оставляешь за собой грязь, а за собой надо убираться, мы же люди, а не голуби на деревьях.

У меня простой вопрос: сколько разрабов (хотя бы из тусующихся здесь) используют одинаковые имена переменных/свойств, но в разном регистре? (не единично, а регулярно используют, т.е. "как правило")

 

[Вурдалак]

У меня простой вопрос: сколько разрабов (хотя бы из тусующихся здесь) используют одинаковые имена переменных/свойств, но в разном регистре? (не единично, а регулярно используют, т.е. "как правило")

Этот вопрос сейчас имеет такое же отношение к теме, как какого цвета носки были у Барака Обамы в день инаугурации, потому что ты сказал, что

в т.ч. и ключей в массивах

а это автоматически означает, что может поменяться и логика приложения.

А тут, - ошибся в буковке и поди потом найди в десятках тысяч строк кода, где буковка не того регистра. Особенно в массивах...

Получается, за свой 15-летний стаж ты ни разу не слышал о backtrace'е?

 

[Chushkin]

А на второе место я бы поставил проблему с интерфейсами. По правильному, если тип "интерфейс", то доступ должен быть только к тому, что описано в интерфейсе, а не ко всем параметрам объекта. По сути, сегодняшний вариант это "дыра".

 

[Вурдалак]

А на второе место я бы поставил проблему с интерфейсами. По правильному, если тип "интерфейс", то доступ должен быть только к тому, что описано в интерфейсе, а не ко всем параметрам объекта. По сути, сегодняшний вариант это "дыра".

С подобными теоретическими замашками тебе дорога писать новый язык программирования, либо сидеть на C++, потому что даже в Java имеется возможность получить инстанс конкретного объекта, даже если он был передан через параметр-интерфейс. Это уже не имеет никакого отношения к PHP.

 

[Chushkin]

На третье место - юникод. Юникод должен быть базовой кодировкой всего и вся, и давно должен быть.

 

[AmdY]

то доступ должен быть только к тому, что описано в интерфейсе, а не ко всем параметрам объекта.

facepalm.jpg

 

[Chushkin]

Вурдалак
Если папа что-то делает и делает неправильно, то это не значит, что дитёнок должен делать тоже и также неправильно.
Я высказал своё IMHO, основанное на опыте и знаниях. Одно из миллионов. Если оно не совпадает с другими, это ещё не значит, что оно неправильное

 

[Вурдалак]

Chushkin, так иди меняй папу, тут уже вопрос в здравом смысле, подобные изменения ведут к другому языку, это не имеет отношения к PHP, это просто бурные фантазии теоретика. Поскольку подобные изменения ломают BC, то сразу встаёт вопрос: какого чёрта ты тут забыл? Иди пиши на Java/Scala новые приложения.

 

[Chushkin]

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

Аааа, теперь я Вас понял - "ПХП должен быть такой, как задуман изначально". Так?
В частности, - "классы долой, это не имеет отношения к ПХП, ибо ПХП не объектный язык". - Поддерживаю!

 

[Вурдалак]

Если бы классы ломали в корне BC, то конечно. Проще было бы назвать это каким-то другим языком. У тебя просто отсутствует здравый смысл, это несколько странно, учитывая что ты имеешь такой большой стаж работы. Видимо, надо было заниматься делами, а не фантазировать.

 

[Chushkin]

Хорошо, - опишите/поясните по пунктам, чем мои предложения ломают Вашу BC?

 

[A1x]

Бессмысленный спор. пхп прекрасен, кроме может быть каких-то мелочей