Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 203
Отлично! Релизы не перестают радовать удобными нововведениями ) Спасибо.
Вызов методов и доступ к свойствам создаваемого объекта — без скобок не понятно, вызывается ли метод свежесозданного объекта или же создаётся объект класса, имя которого возвращает вызванный метод (какая-нибудь хитрая фабрика). Хотя, если без знака доллара, то можно и без скобок, но со скобками надёжнее.
Согласен, мне со скобочками однозначно больше нравится.
Но синтаксис со скобками уже занят с версии 5.4…
php.net/manual/en/migration54.new-features.php
php.net/manual/en/migration54.new-features.php
Забавно — смотрю я на список этих нововведений и не покидает мысль, что PHP всё больше и больше превращается в Python. :)
Что, в общем-то, неплохо. Многого оттуда не хватает в PHP.
Что, в общем-то, неплохо. Многого оттуда не хватает в PHP.
Забавно, что программист на Java, Ruby, JS скажет то же самое. Да и вообще любой программист, использующий в основном N язык будет говорить, что, мол, с их любимого языка N всё слизывают =)
Можно даже в случайном порядке перебрать. Переменное число аргументов — с руби слизали. Вызов методов и свойств у создаваемого объекта — с JS, deprecated с Java, предложенный RFC автором — вообще с C++. Куда катится этот мир? =)
Можно даже в случайном порядке перебрать. Переменное число аргументов — с руби слизали. Вызов методов и свойств у создаваемого объекта — с JS, deprecated с Java, предложенный RFC автором — вообще с C++. Куда катится этот мир? =)
Согласен, лучше бы сделали у всех объектов метод new, как в некоторых языках
Foo::new()->bar;
Bar::new()->foo();
Foo::new()->bar;
Bar::new()->foo();
Вызов методов и доступ к свойствам создаваемого объекта — без скобок не понятно, вызывается ли метод свежесозданного объекта или же создаётся объект класса, имя которого возвращает вызванный метод (какая-нибудь хитрая фабрика)Штоа? Какая ещё хитрая фабрика? В PHP new bar() вернёт экземпляр класса bar, по-другому это не работает.
Забавно, но действительно не работает конструкция, хотя по логике php должна бы.
function bar() { return 'foo'; }
new bar();
function bar() { return 'foo'; }
new bar();
С чего должна-то она работать?
class foo {}
function bar()
{
return 'foo';
}
$fooClass = bar();
$foo = new $fooClass;
по логике ничем не отличается от
class foo {}
function bar()
{
return 'foo';
}
$fooClass = new bar();
Первое работает, второе — нет. Работать должна как раз по логике, т.к. логика здесь от наличия промежуточной переменной, содержащей возврат bar(), никак не меняется.
Правильнее было бы разрешить следующее:
class foo {}
function bar()
{
return 'foo';
}
$fooClass = new bar()();
new в рамках PHP не полноценный оператор, он может принимать только переменную или константную строку без кавычек.
Да, но мы говорим про логику.
В PHP с логикой далеко не всегда окей.
Смотрим, например, на созданный мной когда-то баг (к счастью переоткрыли, хотя изначально перевели в «не баг»): bugs.php.net/bug.php?id=62814
В PHP с логикой далеко не всегда окей.
Смотрим, например, на созданный мной когда-то баг (к счастью переоткрыли, хотя изначально перевели в «не баг»): bugs.php.net/bug.php?id=62814
Тогда уже по логике надо запретить создавать объект по строке из переменной, т.к. new не оператор. Иначе если пойти дальше и такая магия должна работать:
$x = ('cos')(20)
$prop = $obj -> ('property name' . $i); // почему заюзали { .... } вместо ( ) не очень понятно, т.к. -> похож на бинарный оператор.
...
и т.д. и т.п.
… и запретить следующее:
оставив только один вариант инстанциирования:
class foo {}
$foo = new foo;
оставив только один вариант инстанциирования:
class foo {}
$foo = new foo();
… даже еще более магически, через константу =):
class foo {}
define('bar', 'foo');
$fooClass = new bar();
Скажете тоже. «new» в ПХП — конструкция, у конструкций всегда ограниченный синтаксис. Вас же не удивляет (надеюсь), что вот такое не работает:
$a = 'new';
$b = $a bar();
будет работать, правда в JS, но ведь будет)
...$params
как-то странно выглядит
произвольное число параметров может иметь только один тип? или есть возможность указать несколько?
Переменное число аргументов смотрится ужасно, меня ещё в ruby это пугало, когда приходится считать аргументы, чтобы узнать какие переданы.
depricated это логирование, зачем в конструкцию языка запихнули не понятно.
Про неоднозначность new foo()->bar уже писали выше.
Из полезного только неймспейсы и ещё пилить нужно, хотелось бы синтаксис use Foo\*, чтобы импортировать все классы из неймспейса с синтаксисом типа use для трейтов.
Ну и бородатая хотелка — полный тайпхинтинг в php стиле, с приведением. function foo(int $id, string $default = '') {}
depricated это логирование, зачем в конструкцию языка запихнули не понятно.
Про неоднозначность new foo()->bar уже писали выше.
Из полезного только неймспейсы и ещё пилить нужно, хотелось бы синтаксис use Foo\*, чтобы импортировать все классы из неймспейса с синтаксисом типа use для трейтов.
Ну и бородатая хотелка — полный тайпхинтинг в php стиле, с приведением. function foo(int $id, string $default = '') {}
«Смотрятся ужасно» — это не аргумент, а вкусовщина. Сегодня смотрится ужасно, завтра вы уже привыкли и работаете. Depricated нужно чтобы встроенные возможности языка могли использовать не только встроенные функции, но и все остальные — warning, reflection и прочее. Неоднозначности в «new foo()->bar» не больше, чем в «$a || $b && $c». Всего лишь надо знать приоритет операций.
Аргумент был во второй части предложения.
function($a, $b = 0, $c =0, $d)
foo(1, 2) $a = 1, $b = 0, $c =0, $d = 2;
foo(1, 2, 3) $a = 1, $b = 2, $c =0, $d = 3;
foo(1, 2, 3, 4) $a = 1, $b = 2, $c =3, $d = 4;
deprecated — trigger_error. В том же php функции то добавлялись, то удалялись с деприкейтид, для этого нужно менять внутреннюю реализацию функции, а не интерфейс.
$a || $b && $c в нормальной команде этот код не пройдёт код ревью пока скобки не расставят. Другое дело, что оказалось что с функцией вариант не работает и это не добавит двойственности.
function($a, $b = 0, $c =0, $d)
foo(1, 2) $a = 1, $b = 0, $c =0, $d = 2;
foo(1, 2, 3) $a = 1, $b = 2, $c =0, $d = 3;
foo(1, 2, 3, 4) $a = 1, $b = 2, $c =3, $d = 4;
deprecated — trigger_error. В том же php функции то добавлялись, то удалялись с деприкейтид, для этого нужно менять внутреннюю реализацию функции, а не интерфейс.
$a || $b && $c в нормальной команде этот код не пройдёт код ревью пока скобки не расставят. Другое дело, что оказалось что с функцией вариант не работает и это не добавит двойственности.
Вы про это?
Ну так в PHP это уже есть, просто синтаксис иной, станет удобнее, если этот примут.
trigger_error должен помереть.
Хотите сказать, что «$a || $b && $c» слишком сложен для современных программистов, чтобы тут ещё и скобки ставить?
меня ещё в ruby это пугало, когда приходится считать аргументы, чтобы узнать какие переданы.
Ну так в PHP это уже есть, просто синтаксис иной, станет удобнее, если этот примут.
trigger_error должен помереть.
Хотите сказать, что «$a || $b && $c» слишком сложен для современных программистов, чтобы тут ещё и скобки ставить?
$a || $b && $c в нормальной команде этот код не пройдёт код ревью пока скобки не расставят
Вот это, наверное, просто так писали:
www.php.net/manual/en/language.operators.precedence.php
Если для таких очевидных вещей скобки ставить, ну я не знаю…
Такой вот код тоже ревью не пройдёт?
if($error_type&E_PARSE)
return 'This is parse error';Попросят заменить на
if($error_type==E_PARSE)
return 'This is parse error';? А лучше, наверное вот так:
if(((($error_type===E_PARSE))))
return ((((string)'This is parse error'))); //Я не уверен, что это строка, пожалуй стоит проверять ещё и при каждом использовании функции
чтобы наверняка.
Ну и что это за скобочная паранойя?
Простите за сарказм.
Ваш код не пройдёт даже в CI phpcs, это реальность
NotAllowed, Priority: High
Inline control structures are not allowed
Я программирую не один, так что свою гениальность могу засунуть в жопу, главное, чтобы код был понятен всем и стандартизирован. Мне это не сложно, я бы даже, следуя фаулеру, отрефакторил двойное условие, вынеся его в отдельный метод с хорошим названием, сделав код человекочитабельнее.
NotAllowed, Priority: High
Inline control structures are not allowed
Я программирую не один, так что свою гениальность могу засунуть в жопу, главное, чтобы код был понятен всем и стандартизирован. Мне это не сложно, я бы даже, следуя фаулеру, отрефакторил двойное условие, вынеся его в отдельный метод с хорошим названием, сделав код человекочитабельнее.
главное, чтобы код был понятен всем
Вы же не со школьниками в команде?
P.S. пусть школьник не обижаются, есть и исключения.
Я понимаю, что у PHP низкий порог вхождения, но это абсолютно не значит, что останавливаться в его изучении на пункте мануала «Цикл foreach()» и со словами «я всё знаю, я у мамы инженер» идти работать над каким-то проектом с такими же «специалистами» = это нормальное поведение.
Смысл программировать на языке, если человек его не знает? Стандарты нужны для структурирования кода и облегчения командной разработки, без ущерба коду. Если стандарт заставляет вас навешивать лишние скобки, заменять побитовые операции (в том примере это вполне нормально и правильно), переписывать любой механизм, который содержит что-либо, не описанное в книге «Как выучить пых за 24 часа, стать крутым программистом и написать фэйсбук», то, лично моё мнение, такой стандарт нужно сдать в утиль.
Лично я в самом первом блоке кода не вижу никакой гениальности, я вижу код без лишнего говна.
Из самого контрастного — работал на проекте одновременно с малышевым из php core team и студентами бгуир, так что — да, работаю и со школьниками, и с гуру, но сам не страдаю профессиональным снобизмом.
Вот вы привели ссылку на приоритеты, покажите где на ней написано, что приоритет new выше чем у вызова функции?
Вот вы привели ссылку на приоритеты, покажите где на ней написано, что приоритет new выше чем у вызова функции?
Вот вы привели ссылку на приоритеты, покажите где на ней написано, что приоритет new выше чем у вызова функции?
1. Прошу прощения, не совсем понял, что вы имеете ввиду. Если вам не очень сложно, приведите, пожалуйста, пример.
2. Оператор new находится выше всех в таблице приоритетов, этого вам недостаточно? Я думаю, не нужно быть гением, чтобы интерпретировать этот факт, как "new, при наличии каких-либо других операторов, в любом случае будет исполнен первым".
3. С каких пор вызов функции является оператором?
И увеличить безработицу в стране? Не раскачивайте лодку :)
Тогда придётся начать с себя. Пишу на 3 яп, так что могу легко напутать приоритеты.
Ну и тем более if (!$bar = foo()), этот код работает как if (! ($bar = foo()) ), хотя приоритет у "=" меньше чем у "!"
Ну и тем более if (!$bar = foo()), этот код работает как if (! ($bar = foo()) ), хотя приоритет у "=" меньше чем у "!"
и тем более if (!$bar = foo()), этот код работает как if (! ($bar = foo()) )
Код if (!$bar = foo()) работает как if (!$bar = foo()) забудьте о скобках. Вам самому глаза не режет?
хотя приоритет у "=" меньше чем у "!"
Давайте попробуем ещё раз.
www.php.net/manual/ru/language.operators.precedence.php
Специально для вас под табличкой примечание (напишу на русском):
Замечание:
Несмотря на то, что оператор = имеет низший приоритет, чем большинство остальных операторов, PHP все равно позволяет использовать следующую конструкцию: if (!$a = foo()), которая присваивает переменной $a результат выполнения функции foo().
Не читайте выборочно мануал. Вот из-за такого подхода, многие php-шные говнокодеры до сих пор не знают, что если не объявлять массив, а просто присвоить необъявленной переменной элемент, то она автоматически станет массивом $a=[2];.
Хотя в больших проектах лучше всё-таки обнулять.
Вы там выше о стандартах говорите. Какие к чёрту стандарты, подучите базовые вещи.
Так я о чём и говорю, даже стандартный приоритет имеет исключение, этот момент описан в документации в части note.
Там же в Example #2 показана случаи неопределённости конструкций, поведение которых не гарантировано.
Это к тому, что приоритеты не такие однозначные.
А про массив для необъявленных — ты действительно считаешь что нормальный программист столкнётся с таким кодом, я лично думал что будет нотис и мне не стыдно. Считаю что именно говнокодеры пишут такой код в не зависимости от размера проекта.
Там же в Example #2 показана случаи неопределённости конструкций, поведение которых не гарантировано.
Это к тому, что приоритеты не такие однозначные.
А про массив для необъявленных — ты действительно считаешь что нормальный программист столкнётся с таким кодом, я лично думал что будет нотис и мне не стыдно. Считаю что именно говнокодеры пишут такой код в не зависимости от размера проекта.
я лично думал что будет нотис и мне не стыдно
Знаете, что плохо? Не то что, программист чего-то не знает. Все мы люди и всё в голове удерживать просто невозможно. Но если программист сталкивается с странным, на его взгляд поведением, и забивает болт, вместо того, чтобы разобраться как и почему такое происходит, предпочитая порасставлять скобки где, только можно, то это очень печально. Значит человеку это неинтересно, значит человек мыслит по шаблону «да ничё страшного не будет, подумаешь пятьсот лишних знаков и действий-пустышек, которые не несут ни какой смысловой нагрузки, серваку то похер». Как выше, справедливо отметили, обленились нынешние программисты. Я, конечно не застал то время (вернее застал, но в нежном возрасте), когда писалась Windows 3.1, когда ребята сидели ночами возле Dial-up и думали над каждой деталью программы, потому что ресурсы были крайне ограниченны и мощности не позволяли, но когда читаешь статьи о тех временах, чувствуешь себя говном.
Я ставлю скобки не потому что не знаю приоритетов (или не могу их посмотреть в мануале :), а потому что не хочу других заставлять лезть в мануал, чтобы вспомнить у чего выше приоритет: у or или xor.
я не понимаю, в PHP, что — тысяча операторов? В чём состоит сложность? В нежелании запомнить, в лени, в чём?
Какой результат будет у следующего выражения?
php -r "print true ? 1 : true ? 2 : true ? 3 : true ? 4 : 5;"1
Надеюсь, что после того как вы запустите этот код, у вас не останется сомнений в нужности скобочек :) (если что, в документации оно отражено)
Вы всё-таки запустите :) (а потом почитайте про уникальный тернарный оператор в PHP)
Запустил, var_dump() выдаёт (int) 1. Что я делаю не так?
Что именно вы запускаете? (уже ведь намекнул про уникальный тернарный оператор)
Вы определитесь, что вы у меня спрашиваете
— результат print true? 1: true? 2: true? 3: true? 4: 5;
— результат true? 1: true? 2: true? 3: true? 4: 5;
?
Про ассоциативность я знаю, не переживайте, а вот знаете ли вы, как сработает выражение
print true? 1: true? 2: true? 3: true? 4: 5; я сильно сомневаюсь
— результат print true? 1: true? 2: true? 3: true? 4: 5;
— результат true? 1: true? 2: true? 3: true? 4: 5;
?
Про ассоциативность я знаю, не переживайте, а вот знаете ли вы, как сработает выражение
print true? 1: true? 2: true? 3: true? 4: 5; я сильно сомневаюсь
Ессно про «true? 1: true? 2: true? 3: true? 4: 5;», разве не очевидно было?
Какой результат будет у следующего выражения?
php -r «print true? 1: true? 2: true? 3: true? 4: 5;»
Мой ответ: результатом будет вывод текста в консоль. Теперь я надеюсь всё в порядке.
Естественно, неочевидно. Касаемо тернарного оператора — ассоциативность правая, так что нет ничего неожиданного в выводе «4» на экран. И по--моему правая ассоциативность — это одна из тех штук в php, которую сразу замечаешь при изучении тернарного оператора
И что же будет выведено в консоль?
4 будет выведено
И вас это не удивляет? (что они курили? :()
Я учился программированию на паскале, и знаете, когда я сел за пых, для меня было такое облегчение, что нигде нету THEN, NOT, BEGIN, END, разных неудобных какашек, что такой пустяк, как странная логика тернарного оператора не кажется чем-то плохим.
Кстати насчёт «что они курили» =) почитайте на досуге мою статью, а ещё лучше комментарии к ней. Поверьте, по сравнению с другими косяками, тернарный оператор — просто сама очевидность.
Кстати насчёт «что они курили» =) почитайте на досуге мою статью, а ещё лучше комментарии к ней. Поверьте, по сравнению с другими косяками, тернарный оператор — просто сама очевидность.
И это (результат 4) нормальное поведение вложенных тернарных операторов в PHP, что отражено в документации и обсуждалось на хабре.
Как будто я не знаю (читайте ветку целиком)… Проблема только в том, что это «нормальное» поведение нормально только в PHP, поэтому вопрос «что они курили?» очень актуален.
Я вот про это поведение узнал только из документации. Всегда, во всех языках использую скобки в выражениях с более чем одним оператором.
Чтобы там не курили авторы, такой подход — отлично решение не стрелять себе в ногу, когда приходится практически ежедневно прыгать между 2-4 ЯП.
Чтобы там не курили авторы, такой подход — отлично решение не стрелять себе в ногу, когда приходится практически ежедневно прыгать между 2-4 ЯП.
Я вот про это поведение узнал только из документации.
Как я понял в результате этой дискуссии — мануал читать не нужно (а ещё лучше — не думать). Просто создалось такое впечатление, судя по комментариям, вы уж извините конечно, но выглядит всё это как «да не парься, ставь скобки ВЕЗДЕ ВЕЗДЕ ВЕЗДЕ! И ПОБОЛЬШЕ!»
Знание нескольких ЯП — это не повод писать на них абы-как. Я может и танцевать умею, и петь, и быть композитором великим, но только вопрос в качестве, а не в количестве скиллов =)
Скобки в сложных логических выражениях идут защитой от случайного некорректного учета приоритетов операторов. Знание приоритетов не гарантирует отсутствие случайной ошибки.
Из похожего — конструкция «if (42 == $foo)», защищающая от случайного присвоения в языках, где допустимо такое присвоение.
А еще мне просто удобнее визуально смотреть на выражение со скобками, особенно если оно вылезло за пределы одной строки.
Из похожего — конструкция «if (42 == $foo)», защищающая от случайного присвоения в языках, где допустимо такое присвоение.
А еще мне просто удобнее визуально смотреть на выражение со скобками, особенно если оно вылезло за пределы одной строки.
Знание приоритетов не гарантирует отсутствие случайной ошибки
С тем же успехом можно и в скобках запутаться
Я еще со времен паскаля в школе взял за практику закрывать все парные элементы сразу при открытии. То, что сейчас IDE пытаются за нас делать. Отличный способ не запутаться с любыми парными элементами.
Но если сложность выражения такова, что там куча скобок (и это не языки вроде lisp), то стоит задуматься уже о вынесении частей выражения в переменные.
Но если сложность выражения такова, что там куча скобок (и это не языки вроде lisp), то стоит задуматься уже о вынесении частей выражения в переменные.
Нормальные IDE помогают разобраться с многоуровневыми вложениями скобок.
нормальные программисты разбираются в коде и без всяких IDE
Не тысяча, но за полсотни. Ну и да, можно сказать, что и в лени, вернее в экономии ресурсов. Плюс следует учесть, что зачастую люди пишут не только на PHP, а и на других языках, где приоритеты могут быть другими, что сильно осложняет запоминание.
Ну и бородатая хотелка — полный тайпхинтинг в php стиле, с приведением. function foo(int $id, string $default = '') {}
Не надо с привидением! Смысл тайп хинтинга именно в строгом контроле типов.
Переопределение списка аргументов… даёт полную ясность того, что конкретно реализовывает метод, делает код более чистым, избавляя от каскада if-else
и полностью ломает ключевую концепцию ООП — полиморфизм
Это называется ситуативным полиморфизмом, который успешно используется в C++, Java/Scala, Delphi, etc.
В Java то что вы описали, называется перегрузкой методов и к наследованию не имеет отношения. Вашу идею нужно развить, чтобы в одном классе можно было определять несколько методов с одним и тем же названием, но с разным количеством аргументов. Вот тогда это имеет смысл.
В изначальном варианте моё предложение содержало вашу идею. Но, в ходе дискуссии на рассылке выяснилось, что это может сильно поломать обратную совместимость (из-за функции func_get_ars()):
class B {
function foo() { func_get_ars(); }
function foo($bar = null) { func_get_ars(); }
}
$o = new B;
$o->foo(1, 2); // Unpredictable call
Почему же оно будет ломать совместимость, если на данный момент невозможно объявлять 2 метода с одинаковым названием? В вашем примере можно выдать ошибку, что нет подходящего метода, т.к. используется несколько методов с одинаковым названием.
Хм, пожалуй вы правы. В приведенном коде, проблема скорее не в BC, а в том, что неясно какая реализация должна отработать.
Я думаю никакая, можно было бы выдавать Fatal error, раз уж вводят переменное число аргументов, то есть смысл отказываться от магии func_get_ars().
Отказаться от func_get_ars() было бы просто чудесно. Но вот это уже точно сломает BC :)
В содружестве с
И если честно — пускай уже ломают наконец обратную совместимость, ради таких вот фич, старые движки и так выше 5.3 не поднялись, хочешь юзать 5.6 — учитывай нюансы, в противном случае бери старую версию
...$params BC break тоже будет?И если честно — пускай уже ломают наконец обратную совместимость, ради таких вот фич, старые движки и так выше 5.3 не поднялись, хочешь юзать 5.6 — учитывай нюансы, в противном случае бери старую версию
Ну, можно проводить поверку типа что если
func_get_args() вызывается в методе, который имеет «брата» по названию в данном классе, то генерим ошибку. Возможно, ввести модификатор? Не знаю, практикуется ли это среди других языков, но раз у нас^
— динамичный php,
— важна обратная совместимость,
— мы пытаемся сделать кошерную перегрузку,
то нужно ввести модификатор для перегруженных методов. Устанавливать какое-нибудь primary для «главного» метода, или точнее fallback-метода (и тогда назвать модификатор fallback? :)). И в случае, если вызов не совпадает с набором аргументов ни у одного из серии перегруженных методов, вызывать праймери так, как это делается сейчас. Если праймери нет, выбрасывать фатальную ошибку.
— динамичный php,
— важна обратная совместимость,
— мы пытаемся сделать кошерную перегрузку,
то нужно ввести модификатор для перегруженных методов. Устанавливать какое-нибудь primary для «главного» метода, или точнее fallback-метода (и тогда назвать модификатор fallback? :)). И в случае, если вызов не совпадает с набором аргументов ни у одного из серии перегруженных методов, вызывать праймери так, как это делается сейчас. Если праймери нет, выбрасывать фатальную ошибку.
Перегрузку методов сложно сделать при наличии опциональных аргументов — интерптетатору и программисту сложно будет отличить вызов метода с опциональными аргументами от вызова перегруженного метода без аргументов.
class foo {
public static function bar($optional = false){
return $optional;
}
// как бы перегруженный метод, в том же классе или наследнике
public static function bar(){
return true;
}
}
var_dump(foo::bar()); // ??? какой метод должен вызваться ???
Да, это хорошее замечание, спасибо.
Выдавать Fatal error что объявлено 2 метода, которые по сигнатуре одинаковы. И проблема решена.
Ну сейчас так и сделано:
Fatal error: Cannot redeclare foo::bar() ;-))) осталось только добавить подсчёт обязательных параметров и сравнение их типов…
Олег, тут на самом деле очень большая проблема с производительностью возникает. Придется для каждого метода отдельные хештаблицы держать с сигнатурами для каждой перегрузки. Это увеличет время вызова метода и потребляемую память одновременно, что вообще рассматривается как очень плохо. В языках, которые вы приводите, нужные перегрузки, скорее всего (не уверен насчет джавы), резолвятся на уровне компиляции, поэтому рантайм остается при нормальных скоростях.
Хотя, в принципе, насчет таблицы для каждого метода, — наверное можно было бы и в общую таблицу всех сувать, но надо тогда там сразу использовать имена с хешированными до строки сигнатурами. Ну тогда будет сложно резолвить метод, у которого есть опциональные аргументы, если он при этом вызван с опущением каких-то из них… В общем, все это довольно сложно, и уже из-за пинка по производительности я бы не хотел такого.
Хотя, в принципе, насчет таблицы для каждого метода, — наверное можно было бы и в общую таблицу всех сувать, но надо тогда там сразу использовать имена с хешированными до строки сигнатурами. Ну тогда будет сложно резолвить метод, у которого есть опциональные аргументы, если он при этом вызван с опущением каких-то из них… В общем, все это довольно сложно, и уже из-за пинка по производительности я бы не хотел такого.
Ну и самое главное — непонятно кто это реализует
Вот здесь можно посмотреть пример кода к последней версии моего RFC. Основное изменение — это добавление модификаторов dynamic и override. Я полагаю, они должны решить проблему как обратной совместимости, так и падения производительности. Но вот с реализацией — это да, я пока не знаю, как найти человека, который бы за это взялся.
Пощеголяли умным термином? А почитать, что он означает, никак?
Для минусующих: ситуативный (или ad-hoc) полиморфизм — перегрузка функций, т.е. объединение под одним именем нескольких существенно различных реализаций, принимающих различные (по типу, количеству) аргументы.
В чудесном предложении автора реализации метода в подклассе ломает интерфейс
Для минусующих: ситуативный (или ad-hoc) полиморфизм — перегрузка функций, т.е. объединение под одним именем нескольких существенно различных реализаций, принимающих различные (по типу, количеству) аргументы.
В чудесном предложении автора реализации метода в подклассе ломает интерфейс
Т.е. вы полагаете, что перегрузить метод можно только в том же классе, а в наследнике нельзя? Моё предложение не ломает интерфейс, смотрите пример из поста:
Как видите, работают оба варианта.
var_dump($square->calcPerimeter(array(1, 1, 1, 1))); // 4
var_dump($square->calcPerimeter(1)); // 4
Как видите, работают оба варианта.
Вот вам пример контрпример:
Моя функция полагается на интерфейс, заданный классом Figure, и соответствующим образом вызывает метод. Будет вызван метод Figure::calcArea(), но позвольте, откуда, вообще говоря, базовый класс знает, как устроен подсчет в данном случае площади в дочернем?
class Figure {
function calcArea(array $sides) { /* realisation */ }
}
class Square extends Figure {
function calcArea(int $side) { /* realisation */ }
}
/* У меня есть функция, использующая ваш код */
function area(Figure $f, $sides) {
return $f->calcArea($sides);
}
$square = new Square();
area($square, [1, 1, 1, 1]);
Моя функция полагается на интерфейс, заданный классом Figure, и соответствующим образом вызывает метод. Будет вызван метод Figure::calcArea(), но позвольте, откуда, вообще говоря, базовый класс знает, как устроен подсчет в данном случае площади в дочернем?
Вроде ваш пример не отличается от моего. Базовый конечно не знает про реализацию методов в дочернем классе. Наоборот, если аргументы в методе дочернего класса не совпадают с параметрами вызова, то вызов передаётся в родительский класс.
Я видел ваш комментарий в соседней ветке, про то, что должна быть возможность перегружать метод в одном классе. И мне этот подход тоже нравится. Нравится настолько, что я его вкюлчил в изначальный вариант RFC. Вы и dim_s высказали много интересны мыслей. Мне надо некоторое время на подумать, как это всё увязать. Спасибо за интересную дискуссию!
Я видел ваш комментарий в соседней ветке, про то, что должна быть возможность перегружать метод в одном классе. И мне этот подход тоже нравится. Нравится настолько, что я его вкюлчил в изначальный вариант RFC. Вы и dim_s высказали много интересны мыслей. Мне надо некоторое время на подумать, как это всё увязать. Спасибо за интересную дискуссию!
Я поменял периметр на площадь для наглядности, ибо площадь только по сторонам не посчитаешь, надо знать больше о геометрии фигуры, а о ней может знать только дочерний класс
В этом случае Figure::calcArea() должен содержать больше аргументов, а не только $sides, либо этот метод должен быть абстрактынм. Иначе получается, что он нерабочий.
Ну тогда базовый класс должен стать очень умным и уметь все делать за своих наследников, даже еще не написанных.
Нет, в вашем примере с периметром не должен — стороны определяют периметр.
Только зачем городить огород, когда можно было сделать так:
очень ООПшно
Нет, в вашем примере с периметром не должен — стороны определяют периметр.
Только зачем городить огород, когда можно было сделать так:
abstract class Figure {
function __construct($sides) { $this->sides = $sides; }
function calcPerimeter() { return array_sum($this->sides); }
abstract function calcArea();
}
class Square {
function __construct($side) { /* irrelevant */ }
function calcArea() { return $this->sides[0] * $this->sides[0]; }
}
class Polygon {
function __construct($sides, $angles) { /* irrelevant */ }
function calcArea() { /* большая формула, не помню, какая */}
}
очень ООПшно
Или так:
Но я бы не отказался от
interface calculated {
public function calcArea();
}
abstract class Figure implements calculated {
function __construct($sides) { $this->sides = $sides; }
function calcPerimeter() { return array_sum($this->sides); }
}
class Square {
function __construct($side) { /* irrelevant */ }
function calcArea() { return $this->sides[0] * $this->sides[0]; }
}
class Polygon {
function __construct($sides, $angles) { /* irrelevant */ }
function calcArea() { /* большая формула, не помню, какая */ }
}
Но я бы не отказался от
class Calculator {
function __construct($name) { /* irrelevant */ }
function calculate(array $prices) { /* calculation */ }
function calculate(PriceCollection $collection) { /* calculation */ }
}
Не ломает, т.к. Figure это не интерфейс, а класс.
Отвечу тут.
Ок, не ломает, я не так выразился, потому что не совсем так понял идею.
Класс/не класс — важно то, что родительский класс определяет интерфейс для дочерних.
Когда дочерний класс реализует (переопределяет) метод из этого интерфейса, я ожидаю, что именно переопределенный метод и будет вызван в случае: $figure->calcPerimeter(/* args */).
Ан нет, будет вызван базовый метод. Дочерний класс, получается, создает свой метод, который можно вызвать только если знать как (какие именно у него аргументы). Только называется этот метод почему-то так же, как интерфейсный
Ок, не ломает, я не так выразился, потому что не совсем так понял идею.
Класс/не класс — важно то, что родительский класс определяет интерфейс для дочерних.
Когда дочерний класс реализует (переопределяет) метод из этого интерфейса, я ожидаю, что именно переопределенный метод и будет вызван в случае: $figure->calcPerimeter(/* args */).
Ан нет, будет вызван базовый метод. Дочерний класс, получается, создает свой метод, который можно вызвать только если знать как (какие именно у него аргументы). Только называется этот метод почему-то так же, как интерфейсный
Да тут я согласен конечно, в статически типизированных языках такая проблема в этом случае отпадает. Но однако, вы же можете вызвать любой метод у объекта, не зная его класса. Это же динамическая типизация.
Если сделать figure интерфейсом или абстрактным классом с абстрактным методом, тогда будет то чего вы ожидаете, надо будет определить в классе 2 метода с одним названием. Поэтому здесь нужна перегрузка методов, а не то что предложено в статье.
Когда дочерний класс реализует (переопределяет) метод из этого интерфейса, я ожидаю, что именно переопределенный метод и будет вызван в случае: $figure->calcPerimeter(/* args */).
Если сделать figure интерфейсом или абстрактным классом с абстрактным методом, тогда будет то чего вы ожидаете, надо будет определить в классе 2 метода с одним названием. Поэтому здесь нужна перегрузка методов, а не то что предложено в статье.
Это называется непониманием базовых принципов ООП и SOLID, а именно — LSP (принцип подстановки Барбары Лисков), который гласит, что объекты классов-наследников, расширяющих базовый класс, могут использоваться вместо экземпляров базового класса без каких-либо изменений желательных свойств этой программы.
Картинка прилагается:
Картинка прилагается:
class foo {
public $x = 1;
}
class bar {
public $y = 'foo';
}
$x = 'bar';
$bar = new bar;
var_dump((new bar)->y); // foo
var_dump((new $x)->y); // foo
var_dump((new $bar->y)->x); // 1
Это уже давно работает (5.4+).
Дополню ваш пример: ideone.com/s2OGb9 (5.4.4)
В PHP, как всегда, все сделали по-своему, причем абсолютно непостижимым образом
Извлечение функций из пространств имен и модификатор
- Троеточие перед именем переменной — выглядит ужасно. Наверняка хотели сделать «как в Java, но не совсем».
new foo()->xyz;— не вижу ничего поразительного. В нормально написанной грамматике не должно быть разницы, какое выражение использовать перед обращением к полю — вызов функции, литерал или создание нового объекта. Да и вообще, странная практика — создать объект и тут же потерять ссылку на него.- Использование ключевого слова
defaultпри вызове — уж лучше тогда добавить именованные аргументы, потому что это — неудобный костыль.
Извлечение функций из пространств имен и модификатор
deprecated — возможно. Единственная же реально полезная и правильная штука — это исключения вместо Fatal Error. Даже как-то странно, что это ввели только сейчас.
Троеточие перед именем переменной — выглядит ужасно. Наверняка хотели сделать «как в Java, но не совсем».
Как в EcmaScript 6
В PHP ничего ещё не сделал, что вы разоряетесь-то? Что, блин, такое «выглядит ужасно»? Вот по-моему слово «троеточие» выглядит ужасно, потому что такого слова нет. Многоточие перед именем переменной — синтаксис, как синтаксис, ничего удивительного. Ничем не лучше и не хуже решётки перед именем переменной, собачки, скобочек или ещё каких-то значков. Но у многоточия хоть логика есть — это понимаемый многими программистами символ «тут ещё аргументы идут», так сделано в Си, Луа, Гоу и многих других языках.
В new foo()->xyz конечно ничего поразительного нет, просто PHP надовит порядок в синтаксисе, радоваться надо. Создать и потерять ссылку на объект — тут ничего странно нет, например, у нас богатый объект работы с датами, а всё что нам хочется — получить нашу дату в другом формате. Делаем: new Datetime('1977-09-13')->format("%d/%m%Y"), как-то так. Неужели не сталкивались с чем-то похожим?
Ну и использование default — это, конечно, костыль. Неясно зачем было делать ключевое слово, если можно было просто запятые ставить для пропуска, как это уже сделано в конструкции list. Впрочем, такой явный синтаксис даст, думаю, меньше ошибок. А именованные аргументы — это чудесно, после Пайтона мне их в ПХП не хватает. Но это не значит, что default лишит нас именованных аргументов.
В new foo()->xyz конечно ничего поразительного нет, просто PHP надовит порядок в синтаксисе, радоваться надо. Создать и потерять ссылку на объект — тут ничего странно нет, например, у нас богатый объект работы с датами, а всё что нам хочется — получить нашу дату в другом формате. Делаем: new Datetime('1977-09-13')->format("%d/%m%Y"), как-то так. Неужели не сталкивались с чем-то похожим?
Ну и использование default — это, конечно, костыль. Неясно зачем было делать ключевое слово, если можно было просто запятые ставить для пропуска, как это уже сделано в конструкции list. Впрочем, такой явный синтаксис даст, думаю, меньше ошибок. А именованные аргументы — это чудесно, после Пайтона мне их в ПХП не хватает. Но это не значит, что default лишит нас именованных аргументов.
«Выглядит ужасно» — субъективное мнение. Я согласен, что использование многоточия очевидно с точки зрения семантики, но оно хорошо смотрится в после идентификатора, а не перед ним. Например,
Наведение порядка в синтаксисе — это хорошо, но я сильно сомневаюсь, что это так. Больше похоже на то, что для некоторых вещей просто добавляются дополнительные правила в грамматику. Когда я последний раз в нее заглядывал, там были отдельные правила наподобие
Что же касается
String... params в Java. Можно было бы сделать $args... — было бы сильно лучше.Наведение порядка в синтаксисе — это хорошо, но я сильно сомневаюсь, что это так. Больше похоже на то, что для некоторых вещей просто добавляются дополнительные правила в грамматику. Когда я последний раз в нее заглядывал, там были отдельные правила наподобие
return variable и return expr_without_variable. Почему переменная не является частным случаем выражения — тайна, покрытая мраком.Что же касается
default — то зачем сначала делать костыль, чтобы потом сделать как следует? Это же не срочная фича, без которой народ изнемогает, а если сделать сейчас так — то потом придется поддерживать оба варианта.Я согласен, что использование многоточия очевидно с точки зрения семантики, но оно хорошо смотрится в после идентификатора, а не перед ним. Например, String… params в Java. Можно было бы сделать $args… — было бы сильно лучше.
Опять вкусовщина. По мне как угодно хорошо смотрится, вам кажется, что лучше после параметра. Какая разница? Вы привыкните через неделю и перестанете внимание обращать. Вы путаете хорошее с привычным. Вы привыкли как в Джаве, вот вам и кажется, что так красивее.
Это же не срочная фича, без которой народ изнемогает, а если сделать сейчас так — то потом придется поддерживать оба варианта.
Может и изнемогает. Вы же опрос не проводили, так зачем же утверждать то, чего не знаете?
Вы привыкли как в Джаве, вот вам и кажется, что так красивее.
Зачем утверждать то, чего не знаете? :) Я ни разу в жизни не писал на Java. Привычнее мне все-таки
params из C#, однако вариант с многоточием из Java мне все равно кажется более грамотным, хотя бы потому что очень часто хочется объявить функцию с аргументом params — а нельзя, ключевое слово.Вы привыкните через неделю и перестанете внимание обращать.
Честно пытался, но привыкнуть можно к чему-то постоянному. В PHP же именно постоянства-то и не хватает: что синтаксис, что стандартная библиотека постоянно подкидывают неожиданные (и как правило неприятные) сюрпризы. Хаотическое развитие с одной стороны и необходимость обратной совместимости с другой — вот и имеем то, что имеем.
Когда я последний раз в нее заглядывал, там были отдельные правила наподобие return variable и return expr_without_variable. Почему переменная не является частным случаем выражения — тайна, покрытая мраком.
Так, по-моему, подобными нововведениями и стремятся избавиться от этого. То есть будут добавляться все больше новых правил, пока в один прекрасный момент не выкинут их все, не ломая обратной совместимости.
Это было бы бессмысленно. Добавлять новые правила по одному, чтобы потом заменить их все на одно общее — можно же сразу заменить только существующие на одно общее и получить абсолютно тот же результат сразу же.
Я правильно понимаю, что new foo()->xyz это просто замена созданию собственного текучего интерфейса? Или за этим кроется что-то еще?
Переопределение списка аргументов понравилось, но из-за контекста переменного числа аргументов не сразу понял, что вызывается метод из Figure. Что будет, если передадим 2 аргумента в calcPerimeter? При этом смена класса судя по всему не происходит и вот это, как мне кажется, сильно может запутать. Возможно просто пример не совсем удачный.
P.S. Ну и не особо по теме вопрос — где можно посмотреть какая версия php используется сейчас большинством? Подразумеваю, что 5.3 какой-нибудь, т.к. до сих пор вижу на некоторых хостингах 5.2, что практически сводит на нет весь прогресс PHP…
Переопределение списка аргументов понравилось, но из-за контекста переменного числа аргументов не сразу понял, что вызывается метод из Figure. Что будет, если передадим 2 аргумента в calcPerimeter? При этом смена класса судя по всему не происходит и вот это, как мне кажется, сильно может запутать. Возможно просто пример не совсем удачный.
P.S. Ну и не особо по теме вопрос — где можно посмотреть какая версия php используется сейчас большинством? Подразумеваю, что 5.3 какой-нибудь, т.к. до сих пор вижу на некоторых хостингах 5.2, что практически сводит на нет весь прогресс PHP…
Вообще-то если мы создали объект, на стеке должна лежать ссылка на него, а если на стеке объект, то мы должны иметь доступ к этому объекту. Так что это скорее ограничение или недальновидность синтаксического анализатора PHP. Тоже самое было с func()[...] и т.п.
Спасибо, но я, видимо, не настолько суров...) это ответ на какой вопрос из первых двух?)
Скорее всего на первый…
Если на второй, то уже нашел похожий на мой вопрос этот комментарий и ваш ответ)
Скорее всего на первый…
Если на второй, то уже нашел похожий на мой вопрос этот комментарий и ваш ответ)
Да на первый, чтобы понять это нужно хоть немного знать теории из асм-а или байткода (который похож на асм код). PHP компилирует исходный код в байткод, в котором буквально следующая последовательность команд: положить 1 на стек, положит 2 на стек, сложить последние 2 числа из стека и поместить результат на стек. Все в таком разжеванном виде. Для new + доступ к полю почти тоже самое: создать объект положив его на стек, положить на стек имя свойства, взять значение свойства используя 2 последних элемента из стека.
Поэтому я считаю что даже такое должно работать:
Поэтому я считаю что даже такое должно работать:
function(){
return array('x' => new MyObject());
}()['x']->method();
ну некоторые базовые вещи (которые вы написали) я понимаю и пример с функцией понятен, но скорее всего я не так вопрос задал, попробую немного перефразировать.
в php 5.6 будет возможно такое, даже не возвращая $this в каждой функции?:
в php 5.6 будет возможно такое, даже не возвращая $this в каждой функции?:
class foo {
public $x = 5;
public function bar() {
$this->x = 10;
}
public function baz() {
return $this->x;
}
}
var_dump(new foo()->bar()->baz()); // int(10)
Не возвращая
$this в каждой функции, это сделать невозможно. Каждый следующий метод в цепочке вызывается на том объекте, который был возвращен из предыдущего. Как только вы перестанете возвращать $this, контекст потеряется.так ведь и это мне понятно :)
просто мне почему-то показалось, что в php 5.6 решили сделать возврат $this по-умолчанию там, где возврата нет вообще. поэтому и спросил, так ли это.
Первый пример из rfc про Without brackets как раз и отвечает на мой вопрос, что нет, return $this никуда не убрали
просто мне почему-то показалось, что в php 5.6 решили сделать возврат $this по-умолчанию там, где возврата нет вообще. поэтому и спросил, так ли это.
Первый пример из rfc про Without brackets как раз и отвечает на мой вопрос, что нет, return $this никуда не убрали
пример из rfc
<?php
class foo {
public $x = 1;
public function getX() {
return $this->x;
}
public function setX($val) {
$this->x = $val;
return $this;
}
}
$X = new foo->setX(10)->getX();
var_dump($X); // int(10)
?>
Синтаксис 2 (со скобками)
(new foo())->bar()
(new $foo())->bar
(new $bar->y)->x
(new foo)[0]
Вот чего действительно не хватало, обращения с объектами — +5 к динамике)
Совместимость с E_RECOVERABLE_ERROR
Сейчас можно игнорировать восстанавливаемые фатальные ошибки, используя кастомный обработчик ошибок. Заменив их на исключения, мы потеряем такую возможность, ломая, таким образом обратную совместимость.
Имхо все нововведения имеющие проблемы с обратной совместимостью надо вносить все же не в минорные версии, а мажорные.
Это сильно упрощает жизнь разработчикам и админам.
А в чем сложность для старых проектов сохранять определенную версию php?
Просто было бы хорошо, если бы все придерживались единых правил: semver.org/
В тоже время у PHP сложилась традиция — первая циферка означает кардинальную смену, боюсь что даже подхода к программированию на этом языке. Вторая — расширения синтаксиса, всякие плюшки и прочее. Третья — версия билда, патчфиксы всякие и прочее.
Исходя из всего этого — вторую циферку можно считать вполне себе мажорной, а первую — вообще как будто новый язык вышел.
Исходя из всего этого — вторую циферку можно считать вполне себе мажорной, а первую — вообще как будто новый язык вышел.
Фига себе минорные версии, выпускаемые раз в 1-4 года.
В данном случае минорные версии это 5.x.xx, а мажорные 5.x. 6 (если когда-нибудь она выйдет) будет наверное означать глобальную потерю обратной совместимости и/или полную замену движка.
6-ая юникод же :)
Вот поэтому и «если когда-нибудь она выйдет». В том числе ведь юникод будет означать и глобальную потерю своместимости.
Разве что [] для строк перестанет работать (его кто-то вообще использует?), вместо остальных функций все равно давно используются mb_*
Не все так просто. Банальная strlen начнет возвращать другие результаты, а это очень часто используемая функция для определения количества байт (sic!) в строке.
Пожалуй… Можно вынести новые функции в пространство имен std (это же все равно рано или поздно сделают?), а старые оставить как есть (с такой же логикой), через пару версий объявить устаревшими и еще через 2-3-… версии выпилить.
Мне более логичным кажется перевод большинства функций в методы классов и/или в разные (многоуровневые) нэймспэйсы. Типа $string->lenght(), String::lenght($string) или \Std\String\lenght($string) или какие-то их комбинации.
ИМХО, «перевод большинства функций в методы классов» никогда скорее всего не будет :(
Я вот как-то развлекался, вынеся работу со строками (и частично с массивами) в отдельный namespace через C расширение: Str\len('foo'); Str\endsWith('UnifiedPHP', 'PHP'); Arr\filter(Arr\range(20), function($i){...}); и т.п.
Может, использование подобных костылей и есть удел желающих получить подобный синтаксис.
Может, использование подобных костылей и есть удел желающих получить подобный синтаксис.
Развлекался я тоже подобным образом, правда путем создания классов, пытаясь реализовать что-то вроде «Всё объект».
Да я лишь хотел последовательные и понятные имена, порядок аргументов и недостающие «парные» функции.
«Все объект» тоже интересно, вопрос проседания по скорости(
«Все объект» тоже интересно, вопрос проседания по скорости(
Собственно начал копать в сторону расширений, когда частично реализовал на самом PHP, порадовался, а потом решил бенчмарк сделать. Но забросил это дело потом так как не смог разобраться как реализовать перегрузку операторов для некоторых классов без патчиния самого php, а то
$str1->concat($str2) менее удобно было чем $str1 . $str2.
Исключения вместо фатальных ошибок — как я долго этого ждал. Ура!
Как же я хочу, что бы взяли наконец PHP, выкинули нафиг весь мусор, взяли всё самое лучшее, стандартизировали имена\пути и прочее по PSR и выложили в виде новой, мажорной версией PHP, а не пичкали всё новым и новым.
Простите за нескромный вопрос — зачем вы ждете такого именно от PHP? На нем свет клином не сошелся. Есть же Python, Ruby, Node.JS, ASP.NET в конце концов.
Эм мне перечислять все плюсы, начиная от бедных дотнетчиков, пускающих горючие слёзы от того, что новая версия ИЕ присылает им флоаты, вместо интеджеров в input type=«image» до бедных рубистов, которые постоянно переживают, что воркеры опять начнут кушать 99% процессора и по гигабайту памяти на десяток пользователей?
Перечисление всех «за» и «против» пыха займёт много строек и буковок, и даже не взирая дичайшую свалку функций и безумие в типах я считаю его самым лучшим, что есть на данный момент под серверсайд, может из-за того, что я его лучше знаю, может из-за Java-like синтаксиса без строгой типизации — не важно. Важно, что топик про PHP 5.6 и разговор следует вести именно о нём, разве не так?
Перечисление всех «за» и «против» пыха займёт много строек и буковок, и даже не взирая дичайшую свалку функций и безумие в типах я считаю его самым лучшим, что есть на данный момент под серверсайд, может из-за того, что я его лучше знаю, может из-за Java-like синтаксиса без строгой типизации — не важно. Важно, что топик про PHP 5.6 и разговор следует вести именно о нём, разве не так?
мне например совсем не нравится синтаксис в руби и питоне, нода только развивается и это вообще совершенно другой мир и пока другие задачи6 asp.net — я так понимаю это майкрософт, а значит не открыто, скорее всего запустится только на винде — спасибо, не нужно.
Другие подходы. В чем-то лучше, в чем-то хуже, но, главное, другие.
Опускаем указание значений для необязательных аргументов:
function create_query($where, $order_by, $join_type = '', $execute = false, $report_errors = false) { }
create_query('deleted=0', 'name', default, default, /*report_errors*/ true);
Не надо делать функции, содержащие более трех аргументов, и не прийдется придумывать костыли, решающие связанные с этим проблемы.
function create_query($where, $order_by, $join_type = '', $execute = false, $report_errors = false) { }
create_query('deleted=0', 'name', default, default, /*report_errors*/ true);
Не надо делать функции, содержащие более трех аргументов, и не прийдется придумывать костыли, решающие связанные с этим проблемы.
Я тоже не понимаю смысла этого, если уже ввели укороченный синтаксис множественных аргументов и в предложениях висит RFC с именованными аргументами.
Плюс к этому — безумия добавляет указание «default» в качестве ключевого слова, следовательно:
1) Надо знать, что аргумент имеет дефолтное значение и проще указать именно его (пустую строку, null или другое), а не писать default
2) Почему именно «default», не проще ли просто запятыми пропускать?
Плюс к этому — безумия добавляет указание «default» в качестве ключевого слова, следовательно:
1) Надо знать, что аргумент имеет дефолтное значение и проще указать именно его (пустую строку, null или другое), а не писать default
2) Почему именно «default», не проще ли просто запятыми пропускать?
create_query('deleted=0', 'name',,, true);
Имхо, пропуск запятыми невозможно прочитать. Взгляните бегло на эту строчку с
create_query и скажите, сколько времени вам понадобится чтобы определить, в какой по счету параметр передано значение true? 
null не катит. Потому как разработчику прийдется как сейчас писать:
default самое нормальное, особенно если IDE будет подсвечивать это дело
if($a === null) {$a = true}
if($b === null) {$b = self::BLA_BLA}
default самое нормальное, особенно если IDE будет подсвечивать это дело
Во многих стандартах кода как раз требуют ставить единственно-возможным дефолтом — null. Это позволяет обрабатывать дефолты для объектов в том же стиле, что и для остальных типов данных. Та же ситуация с более сложной логикой определения дефолтов.
Ну и плюс, не совсем понимаю, зачем логику выбора дефолтов выносить в сигнатуру функции/метода.
Короче, лично я уже давно перешёл на инкапсулированные дефолты внутри метода/функции и на null-значения для необязательных параметров в сигнатуре.
Ну и плюс, не совсем понимаю, зачем логику выбора дефолтов выносить в сигнатуру функции/метода.
Короче, лично я уже давно перешёл на инкапсулированные дефолты внутри метода/функции и на null-значения для необязательных параметров в сигнатуре.
Было бы здорово, если б в 5.6 запилили как в Java возможность определения одноименных методов класса с разным набором типизированных аргументов. Но очевидно пока такое в чистом виде реализовать нельзя без статической типизации. Но хотя бы с разным количеством аргументов вариант был бы кстати.
Оторвать руки у любителей писать такое:
И заставить использовать унифицированное, понятное и не требующее особой поддержки ЯП:
Всё равно в итоге массив получаете. Нафига вам ещё какой-то сахар для того, что надо выпилить к чертям из языка и всё.
function foo($var, ...$params)
{
...
}
И заставить использовать унифицированное, понятное и не требующее особой поддержки ЯП:
function foo($var, array $params = array())
{
...
}
Всё равно в итоге массив получаете. Нафига вам ещё какой-то сахар для того, что надо выпилить к чертям из языка и всё.
function foo($var, array $params = array())
{
...
}
function foo($var, array $params = [])
{
...
}
fixed и уже не столь унифицированное
Но в любом случае предложенный синтаксис лаконичней, просто небольшой сахарок, не ломающий BC
Да, но тогда перед вызовом foo() массив $params приедтся собирать вручную. С новым синтаксисом будет удобнее.
Там вон ниже уже привели второй RFC из этой же темы wiki.php.net/rfc/argument_unpacking очень приятно в некоторых местах отказаться от call_user_func_array. Поэтому в паре достаточно неплохая функциональность.
function fn($reqParam, $optParam = null, ...$params) { }
Не очень-то практично: с появлением [короткого] синтаксиса массивов нет почти никакой разницы с fn($reqParam, $optParam = null, array $params = []).
Куда уместнее было бы аналогичным образом избавиться от call_user_func_array. Скажем, так:
function fn($param1, $param2, $param3) { }
$args = [1, 2, 3];
fn(...$args);
Или даже так
$more_args = [2, 3];
fn(1, ...$args);
Это намного чаще нужно — в фабриках, DI и т.п.
Буду краток: wiki.php.net/rfc/argument_unpacking =)
То, что дело дошло до перевода фаталов в исключения — это очень хорошо. Если это примут, писать и обслуживать приложения станет проще и удобнее. Жалко, что до этого добрались так поздно.
Вообще, в PHP есть только несколько серьезных концептуальных проблем. Вот фаталы — одна из них. Может их по-тихоньку выпилят и язык обретет новую жизнь. По сути главное, что надо еще сделать, — это полностью переписать все стандартные функции, классы и все, что с ними идет, но объектный и единый стиль, избавиться от хаоса именований и подходов. Т.е. привести всю внутрянку в нормальный вид.
Это что касается самого языка. А что касается среды исполнения, то тут надежды на HHVM. Если Facebook не забъет на этот проект и сообщество его подхватит, это станет новая дефолтовая среда для исполнения PHP, на порядок лучше старой интерпретации.
Если каким-то чудом срастется это все, то у PHP однозначно начнется новая жизнь.
Вообще, в PHP есть только несколько серьезных концептуальных проблем. Вот фаталы — одна из них. Может их по-тихоньку выпилят и язык обретет новую жизнь. По сути главное, что надо еще сделать, — это полностью переписать все стандартные функции, классы и все, что с ними идет, но объектный и единый стиль, избавиться от хаоса именований и подходов. Т.е. привести всю внутрянку в нормальный вид.
Это что касается самого языка. А что касается среды исполнения, то тут надежды на HHVM. Если Facebook не забъет на этот проект и сообщество его подхватит, это станет новая дефолтовая среда для исполнения PHP, на порядок лучше старой интерпретации.
Если каким-то чудом срастется это все, то у PHP однозначно начнется новая жизнь.
Фатальные ошибки это не концептуальная проблема, а ваше нежелание принять и начать использовать подход отличный от исключений. Так же не нужно забывать что PHP сочетает в себе ООП и функциональное программирование (в котором исключениям в их текущем виде нет места), поэтому никто не станет просто так их выпиливать.
1. Мое нежелание тут не причем. Подход должен быть единым, а не половина ошибок через исключения, вторая — через фаталы. Ничего нормального в этом нет при любом раскладе вне зависимости от моего и вашего понимания этого вопроса. Подчеркиваю — в этом нет даже нормальности, не говоря о том, что это может быть хорошо. Такой подход был актуален до появления исключений.
2. Я не против сочетания ООП-подхода и процедурного, если для ООП все написано как положено, в объектном стиле. Т.е. полное дублирование (естественно через обертки) всего коробочного функционала — для работы в процедурном стиле, и ООП. А то, что сейчас все перемешано — это одна из серьезнейших проблем языка.
2. Я не против сочетания ООП-подхода и процедурного, если для ООП все написано как положено, в объектном стиле. Т.е. полное дублирование (естественно через обертки) всего коробочного функционала — для работы в процедурном стиле, и ООП. А то, что сейчас все перемешано — это одна из серьезнейших проблем языка.
Сейчас ничего не мешает перевести большую часть ошибок в исключения и те кому это нужно уже давно так и сделали, насколько нужны исключения вместо оставшихся? Вот, например, что делать если вылезла E_CORE_ERROR?
А то, что сейчас все перемешано — это одна из серьезнейших проблем языка.
Проблема только в том, что это гораздо удобнее чем чисто ООП подход когда приходится создавать или объекты ради объектов или статичные классы с набором функций (которые по сути ничем не отличаются от обычных функций).
А вы точно не путаете функциональное программирование с процедурным?
Одна из проблем PHP в том, что практически любой код невозможно написать без использования «процедурно-ориентированной» стандартной библиотеки. И когда в теле метода приходится использовать процедурный подход (от strlen() до resource переменных) то это вызывает диссонанс и желание перейти на ЯП, где «всё объект».
Одна из проблем PHP в том, что практически любой код невозможно написать без использования «процедурно-ориентированной» стандартной библиотеки. И когда в теле метода приходится использовать процедурный подход (от strlen() до resource переменных) то это вызывает диссонанс и желание перейти на ЯП, где «всё объект».
Да, вы правы.
Но вот как раз strlen и прочее удобнее чем объекты:
В Java так и есть «всё есть объект», но лямбды всё равно добавили — не от хорошей жизни наверное?
Но вот как раз strlen и прочее удобнее чем объекты:
srtlen($var); // тип может быть почти любой
((string) $var)->length(); // на фиг, на фиг ...
В Java так и есть «всё есть объект», но лямбды всё равно добавили — не от хорошей жизни наверное?
Согласен, но с небольшой оговоркой. Вот как раз про strlen. Я, лично, не сторонник перевода базовых типов в объекты. Т.е. я не хочу, чтобы все строки внезапно стали объектами. И тем более не хочу раздвоения, когда есть и string, и String. Это никому не нужно. Но все методы для работы со строками привести к виду String::length() — вот это то, чего я хочу. Более того, это даже сделать можно относительно не сложно. Надо только научиться писать расширения, потому что такие обертки на PHP будут тормозить приложение.
Это никому не нужно.
Не говорите за всех :)
Но все методы для работы со строками привести к виду String::length() — вот это то, чего я хочу.
Не вижу особого смысла. Почему не к виду \String\length()?
Не говорите за всех :)
Даже, если будет по вашему, но оно будет работать не медленнее, чем сейчас, я не против. Я против вариантов с приведением типов (даже автоматическим), или варианта, когда вся память будет засрана строками-объектами.
Не вижу особого смысла. Почему не к виду \String\length()?
Потому что это по прежнему процедурный стиль. Например, можно засунуть свою функцию в \String. Я против этого, будет тоже самое, что с глобальными массивами. С другой стороны можно сделать ProjectString extends String, чтобы расширить функционал, но сохранить целостность. Для нэймспейсов так не сделаешь.
Я тоже рад, что фаталы можно будет переводить в исключения. И уж «начать использовать подход отличный от исключений» точно не про меня, поскольку я начинал писать ещё на PHP3, где исключений не было вообще.
И за 10+ лет я не видел ни одного проекта на PHP на котором бы использовалось чистое ФП, без императивных возможностей. Ну и главное — если вы не используете исключения в своем проекте, то так же будете получать фатальные ошибки и можете их обрабатывать привычным для вас способом. Это лучший компромисс чем «заставлять» оопщиков и процедурщиков на большую часть стандартных функций писать обертки, отлавливающие ошибки и переводящие их в исключения.
И за 10+ лет я не видел ни одного проекта на PHP на котором бы использовалось чистое ФП, без императивных возможностей. Ну и главное — если вы не используете исключения в своем проекте, то так же будете получать фатальные ошибки и можете их обрабатывать привычным для вас способом. Это лучший компромисс чем «заставлять» оопщиков и процедурщиков на большую часть стандартных функций писать обертки, отлавливающие ошибки и переводящие их в исключения.
Насколько часто в ваших проектах возникают фатальные ошибки?
По 10 раз на дню.
А какая их часть не может быть переведена в исключения сейчас?
ЗЫ: как то сомнительно что в нормальных проектах десяток фатальных ошибок в день это нормально.
ЗЫ: как то сомнительно что в нормальных проектах десяток фатальных ошибок в день это нормально.
Собственно большая часть переведена, но костылями типа проверки существования метода перед его вызовом. Проблема в том, что на одном логическом действии может возникнуть куча ошибок, которые по бизнес-логике фатальными не являются, но по логике PHP являются, и приходится для атомарной по бизнес-логике попытке что-то сделать городить кучу проверок для каждого возможного типа фатальных ошибок, а результатом этих проверок является выбрасывание одного типа исключения.
В реальных проектах возникают. Только это не важно. Важен подход.
Функциональщина в php чисто номинальная, для написания небольших кусков в ФП-стиле вполне подойдет, но не более. Без restarts смысла в плане обработки ошибок немного. Проще с исключениями по аналогии с handler-case в лиспе.
Давно ждал такого
Но еще бы
function create_query($where, $order_by, $join_type = '', $execute = false, $report_errors = false) { }
create_query('deleted=0', 'name', default, default, /*report_errors*/ true);
Но еще бы
class B {
public function n ($a, $b = 456) {
return $a . $b;
}
}
class A extends B {
public function m ($a = 123, $b = default) {
return parent::n($a, $b);
}
}
$a = new A();
echo $a->m(); // 123456
echo $a->m(000); // 000456
echo $a->m(321, 321); // 321321
echo $a->m(default, 321); // 123321
Переопределение списка аргументов
Может кто-то подсказать где найти обсуждение или rfc сейчас этой фичи?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Функции в PHP 5.6 — что нового?