Комментарии 23
Array dereferencing через :> ужасен. Очень надеюсь, что так не сделают.
У нас на работе подумали также, и подумали что $arr:some:arr:''key with space'' было бы хорошо.
Имхо, из-за синтаксиса конкатенации через точку, лучше вообще не пытаться «родить сахарок», а оставить уж как есть. Есть в языке задачки поважнее.
Конкатенация через точку это мегафейл…
Вообще интересно сделали в Scala, отказавшись от ++ как инкремента и сделав его конкатенацией коллекций. Ни что не мешало PHP поступить так же добавить конструкцию вида T_STRING ++ T_STRING.
Жаль что этого не произойдет ни когда, по соображениям огромной несовместимости :(
Вообще интересно сделали в Scala, отказавшись от ++ как инкремента и сделав его конкатенацией коллекций. Ни что не мешало PHP поступить так же добавить конструкцию вида T_STRING ++ T_STRING.
Жаль что этого не произойдет ни когда, по соображениям огромной несовместимости :(
Кстати, синтаксис через: может конфликтовать (по крайней мере в голове разработчика) с тернарным оператором. Последний и так в php сделан «не как у людей», а если его смешать в одной конструкции с такой индексацией…
Вариант выкинуть кавычки, оставив только скобки, в свою очередь конфликтует с неявным созданием констант на лету при их использовании.
В общем, лучше бы не трогали :)
Вариант выкинуть кавычки, оставив только скобки, в свою очередь конфликтует с неявным созданием констант на лету при их использовании.
В общем, лучше бы не трогали :)
Э… А что в тернарном операторе PHP «не как у людей»? Я никакой разницы с теми же Си и Java не замечал.
Используйте в одном выражении хотя бы два тернарных без круглых скобок. Порядок выбора веток не типичен. Вроде даже пост был как-то на Хабре по этому поводу.
А, понял. Приоритет тернарных операторов в общем случае не стандартизирован, так что при их вложении я использую скобки в любом языке.
Кроме того, вложенные тернарные операторы — это уже повод задуматься о структуре кода. В моей практике такое бывает только в редких постыдных случаях торопливых костылей :) Это же чистый write-only код. Его потом читать замучаешься.
Кроме того, вложенные тернарные операторы — это уже повод задуматься о структуре кода. В моей практике такое бывает только в редких постыдных случаях торопливых костылей :) Это же чистый write-only код. Его потом читать замучаешься.
Двойной тернарный оп я у себя допускаю у ветвлений, если вся конструкция влезает в одну строку (80-120 символов). Возможно с вынесением подвыражений.
Но речь-то не о порядке, а комбинировании тернарных оп с вариантом индексации через все тот же ":". Имхо будет полный фарш. Лучше б уж как с объектами сделали, если руки у них чешутся что-нить добавить.
Но речь-то не о порядке, а комбинировании тернарных оп с вариантом индексации через все тот же ":". Имхо будет полный фарш. Лучше б уж как с объектами сделали, если руки у них чешутся что-нить добавить.
Всегда спокойно относился к различным предложением, но это тоже вызвало бурное негодование.
Хороший выпуск. Особенно порадовали новые RFC. Особенно предложенный новый синтаксис для массивов.
Спасибо за ваш труд в очередной раз ) Кстати, по прототипам я когда-то давно тоже делал библиотечку с трейтами: Prototype
Предложения с кавычками и новым синатксисом для массивов плохие.
Если отменить обязательные кавычки в объявлении ключей и значений массивов, то как там отличить строку от константы?
Еще один синтаксис для массиов мало того выглядит не очень (но это вкусовщина), так он еще и менее гибкий — как задать ключ массива перемнной?
$myArray:>$foobar:>$andSoOn:>moreKeys
Не будет ли такой же путаницы с константами?
А как задать числом или выражением?
$myArray:>($i+$j)
Ерунда какая-то, синтаксический сахар ради синтаксического сахара, причем еще и совсем не похожий на синтаксис других ЯП.
Если отменить обязательные кавычки в объявлении ключей и значений массивов, то как там отличить строку от константы?
Еще один синтаксис для массиов мало того выглядит не очень (но это вкусовщина), так он еще и менее гибкий — как задать ключ массива перемнной?
$myArray:>$foobar:>$andSoOn:>moreKeys
Не будет ли такой же путаницы с константами?
А как задать числом или выражением?
$myArray:>($i+$j)
Ерунда какая-то, синтаксический сахар ради синтаксического сахара, причем еще и совсем не похожий на синтаксис других ЯП.
Согласен, будет выглядеть чужеродно, чем им скобочки [] не угодили? :)
Если отменить обязательные кавычки в объявлении ключей и значений массивов, то как там отличить строку от константы?
Сначала проверять существование константы и если её нет использовать строку (собственно оно сейчас так и работает, только еще нотис выбрасывает).
Да, и это на мой взгляд проблема, от которой надо избавляться (от E_STRICT до deprecated), а не развивать дальше бардак.
Синтаксическая конструкция должна означать всегда одно и тоже, и не зависеть от хода выполнения скрипта. На всяк случай: я имею ввиду именно семантическое значение синтаксической конструкции, а не значение результата ее интерпретации.
Синтаксическая конструкция должна означать всегда одно и тоже, и не зависеть от хода выполнения скрипта. На всяк случай: я имею ввиду именно семантическое значение синтаксической конструкции, а не значение результата ее интерпретации.
Для деплоя по ftp есть еще неплохая утилита github.com/dg/ftp-deployment
NikiC совсем заигрался. Всякий раз, когда я буду видеть вызов вида foo()() — я буду от всей души желать написавшему это гореть в аду.
Прелесть РНР всегда была в читабельности кода — читать код было почти так же легко, как и писать. То есть, поклонники стиля «фигак-фигак — и на продакшен» не могли сильно поднагадить тем, кто будет после них отлаживать код. Но в последние годы сообщество серьёзно работает над тем, чтобы окончательно похоронить читабельность.
а этого Andrea Faulds я затопчут свои же, я надеюсь
Прелесть РНР всегда была в читабельности кода — читать код было почти так же легко, как и писать. То есть, поклонники стиля «фигак-фигак — и на продакшен» не могли сильно поднагадить тем, кто будет после них отлаживать код. Но в последние годы сообщество серьёзно работает над тем, чтобы окончательно похоронить читабельность.
а этого Andrea Faulds я затопчут свои же, я надеюсь
foo()()
Тут наоборот радоваться надо что PHP становится нормальным (подобные конструкции везде работают), и если кому-то и желать гореть в аду то только тому криворукому программисту который изначально не смог это реализовать.
Я ничего удивительного в этом не вижу. Write-only языки и подходы шагают по планете.
Ширпотреб вытесняет вещь. Машина делается со сроком службы три года, гаджет — полгода. Почему программа должна работать дольше? Написал шустренько — и в продакшен. А если что-то сломалось, то проще новую написать, чем со старой разбираться.
Ширпотреб вытесняет вещь. Машина делается со сроком службы три года, гаджет — полгода. Почему программа должна работать дольше? Написал шустренько — и в продакшен. А если что-то сломалось, то проще новую написать, чем со старой разбираться.
ИМХО лучше бы дали доступ к ключам массива через стрелочку ->, раз уж нельзя точку использовать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дайджест интересных новостей и материалов из мира PHP № 42 (1 — 16 июня 2014)