Двойное двоеточие позволяет визуально определить где обращение к объекту, а где вызов статики:
А здесь обращение к объекту или к статике?
class OtherClass extends MyClass
{
public function myFunc()
{
parent::myFunc();
echo "OtherClass::myFunc()\n";
}
}
А т.ж.
So, word of warning: apparently, some PHP installations will let you use a $instance::method(), while others don't.
Ну и зачем оно нужно было чтоб потом юзвери путались что им писать?
Чтоб обосновать выбор стрелочки в качестве доступа к объектам — надо пойти чуть глубже: Распространённая практика использования символа "+" для конкатенации строковых значений.
Это все понятно. Череда обратных совместимостей породила монстра. Нет, обратная совместимость, безусловно, нужна. Даже важнее чем новые фичи. Но Вы же сами оголяете противоречие. С одной стороны Вы говорите, что синтаксис был обусловлен уже существующими конструкциями языка, и с другой пишете что вам полученный синтаксис нравится даже больше. Совпадение? Возможно. Но больше похоже на оправдание.
Наблюдаю краем глаза за лавинообразным развитием пхп последних лет, и сделал парадоксальный вывод. Чем быстрее пхп развивается, тем быстрее он умрет. Очень просто. Из него сделают недо-яву (без юникода, потоков, толковой типизации, тормозную, с «шумным» синтаксисом), и люди получат больше оснований сравнивать.
А сравнив, сделают очевидный вывод.
Процесс запущен.
Мой прогноз: пхп умрет, когда отменят доллар в имени переменных.
Груви чем хорош, он может быть одновременно и javascript'ом и java'ой — за счет опциональной типизации. Очень напоминает Dart в этом плане.
Еще одна заманчивая особенность — полнейшая динамичность. Например, не только резолвинг методов выполняется по типу получателя (виртуальность, как в java), но и резолвинг методов по типу сигнатуры в runtime (мультиметоды, как в obj c, smalltalk). В общем-то из за такой сверх-динамичности на груви весьма удобно городить всякое метапрограммирование и DSL. В ущерб скорости, конечно, но всегда можно тормозящее написать на java.
Ну если вспомнить, для чего вообще ввели в жаве эти дефолты, то все станет понятно. А ввели для того, чтоб расширить базовые интерфейсы коллекций лямбда-примочками, не поломав уже написанный код, явно или неявно использующий оные интерфейсы.
А здесь обращение к объекту или к статике?
А т.ж.
Ну и зачем оно нужно было чтоб потом юзвери путались что им писать?
Это все понятно. Череда обратных совместимостей породила монстра. Нет, обратная совместимость, безусловно, нужна. Даже важнее чем новые фичи. Но Вы же сами оголяете противоречие. С одной стороны Вы говорите, что синтаксис был обусловлен уже существующими конструкциями языка, и с другой пишете что вам полученный синтаксис нравится даже больше. Совпадение? Возможно. Но больше похоже на оправдание.
Понятно, что можно найти тысячу оправданий несовершенству парсера. Туда же ::, \, -> и прочие.
Что такого принципиально невозможного? Почему в куче языков возможно, а в пхп нет?
А сравнив, сделают очевидный вывод.
Процесс запущен.
Мой прогноз: пхп умрет, когда отменят доллар в имени переменных.
И оттого работает чудовищно неэффективно по памяти.
Еще одна заманчивая особенность — полнейшая динамичность. Например, не только резолвинг методов выполняется по типу получателя (виртуальность, как в java), но и резолвинг методов по типу сигнатуры в runtime (мультиметоды, как в obj c, smalltalk). В общем-то из за такой сверх-динамичности на груви весьма удобно городить всякое метапрограммирование и DSL. В ущерб скорости, конечно, но всегда можно тормозящее написать на java.
Не показывает ли это что Groovy лучшая альтернатива?
А нужно оно? Золотое правило: работает — не трожь.
То что можно сделать библиотеками — не нужно делать на уровне языка. Однородность и простота синтаксиса это плюс а не минус.
Интересно бы еще сравнить с Java-подходом в плане эффективности. Кстати, судя по исходникам, подход Java проще всего:
У Вас устаревшие данные, см. www.rsdn.ru/forum/java/4988346?tree=tree