Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 155
То, как это предполагается использовать, представлено здесь. Я подумал разработчикам будет удобнее разобраться читая пример.
Жесть "… После очередной дискуссии в IRC принято решение..."
Типа скоро «ссора в аське между Абамой и Бушем привела к массовым гонениям сексуальных меньшинств на север.» :)
Типа скоро «ссора в аське между Абамой и Бушем привела к массовым гонениям сексуальных меньшинств на север.» :)
А что вас смущает? Отстутствие по представителю от Google, MS, IBM, Intel, Sun, и т. д.? Фамильного замка английского лорда и красных ковровых дорожек?
Не боги горшки обжигают, в опенсурсе так часто, зайдите на irc.freenode.net.
Не боги горшки обжигают, в опенсурсе так часто, зайдите на irc.freenode.net.
Ну тут всё зависит от того, кто этой технологией пользуется. В разработке стандарта JS учавтсвуют члены ECMA TC 39: MS, Yahoo, Mozilla, Google, Opera, Adobe… Так же Google, IBM, Sun, Oracle, SAP, Red Hat строят свой бизнес на Java и поэтому голосуют за JSR.
Оба проекта — опенсорсные, всё скорее зависит от «размаха» технологии. Если проектом пользуются энтузиасты — то и вопросы решаются в IRC или лидерами проекта, в то время как крупные компании не будут вкладываться в проект, судьба которого может поменяться без их ведома — что вполне логично.
Оба проекта — опенсорсные, всё скорее зависит от «размаха» технологии. Если проектом пользуются энтузиасты — то и вопросы решаются в IRC или лидерами проекта, в то время как крупные компании не будут вкладываться в проект, судьба которого может поменяться без их ведома — что вполне логично.
да, это я знаю, сам был раньше программистом на java, просто это никак не гарантия разумности решения, и порой вот такие простые обсуждения в IRC генерируют куда-более свежие идеи, чем те, что предлагаются комитетами.
Ну гарантий разумности решения не даст никто. Другое дело, что JCP даёт гарантии стабильности и совместимости. Вам, как railor'у наверное известен путь ruby на сервере: lighttpd, mongrel, thin, mod_rails… И это всего за 4 неполных года такая чехарда. А ведь ещё есть много подобных тем: 1.9, отсутствие спецификации. Безусловно, на этапе становления это может быть и хорошо, но Java уже давно его прошла, а JSR принимаемые последнее время вполне разумны.
Обсуждения везде проходят в mail-lists, другое дело, что JSR требуют чёткой спецификации, а не странички в Wiki, а так же весь процесс более формальный — в остальном всё тоже самое. Впрочем, это никак не влияет на развитие сторонних проектов на Java.
Обсуждения везде проходят в mail-lists, другое дело, что JSR требуют чёткой спецификации, а не странички в Wiki, а так же весь процесс более формальный — в остальном всё тоже самое. Впрочем, это никак не влияет на развитие сторонних проектов на Java.
Че-то не понял, а чем плохо использовать ::?
Породили какой-то совершенно неочевидный символ, да еще потенциально проблемный.
Породили какой-то совершенно неочевидный символ, да еще потенциально проблемный.
Слышал про статические методы?
Мы что уже на ты?
Интересно как: почему же это не мешает остальным языкам? В питоне вообще достаточно одной точки для всего. И никакого зоопарка из "::", "->" а теперь еще и "\"
Интересно как: почему же это не мешает остальным языкам? В питоне вообще достаточно одной точки для всего. И никакого зоопарка из "::", "->" а теперь еще и "\"
Потому что устройство интерпретатора слабо поддерживает разбор контекстов и т. п. вещей.
Так надо писать «Слышал об убогости интерпретатора?» и сразу станет ясна ваша точка зрения
Чем проще интерпретатор, тем быстрее и надежнее он работает. Если в нем до сих пор не было контекстного разбора, то и незачем его вводить из-за такой незначительной темы, как неймспейсы. Естественно проще поменять синтаксис. А какой там будет символ, ну не все ли равно? Можно подумать что после официально ввода неймспейсов, это будет самый популярный оператор в программах. Как не было его, так и не будет в подавлающем большинстве кода.
Диалог творит чудеса, как вам такой вариант «Интерпретатор пхп прост, а значит быстр и надежен. Операция :: занята, имеет ли смысл усложнять итератор для единственной редко используемой команды?»
Теперь ответ :)
В первом коментарии ссылка на код, вам такое нравится?
То есть вы считаете нормальным вводить в язык конструкцию которая выглядит уродливо?
Конечно её использования будут избегать, а значит не будет выполнена основная задача — сделать программирование проще, удобнее. Ведь именно с этой целью вводится новая функциональность.
В первом коментарии ссылка на код, вам такое нравится?
То есть вы считаете нормальным вводить в язык конструкцию которая выглядит уродливо?
Конечно её использования будут избегать, а значит не будет выполнена основная задача — сделать программирование проще, удобнее. Ведь именно с этой целью вводится новая функциональность.
Что значит «уродливо»? На вкус и цвет? Я лично не вижу никакого уродства в символе \. По мне любой другой бы подошел, и :::, и… Лишь бы это не был ::, потому что это будет взрывать мозг, как интерпретатору, так и человеку, который в этом коде будет разбираться.
Если вы читали протокол, то там ясно написано, почему не может быть оставлен символ :: Там дело даже не в контекстных возможностях интерпретатора, а то, что придется делать autoad всегда.
Если вы читали протокол, то там ясно написано, почему не может быть оставлен символ :: Там дело даже не в контекстных возможностях интерпретатора, а то, что придется делать autoad всегда.
Чесслово какой-то странный мозг. Взрывается…
Я чуть ниже привел код на С++ — класс это тот же неймспейс.
В пхп в данный момент класс также неймспейс
Хоть это мозг не взрывает?
Ну а если вам не важно какой разделитель использовать может лучше :) или :>, я бы предложил еще %)
Я чуть ниже привел код на С++ — класс это тот же неймспейс.
В пхп в данный момент класс также неймспейс
php > class Foo { function test() { return 'test'; } }
php > Foo::test();
php > echo Foo::test();
test
php > function test() { return 'another test'; }
php > echo test();
another test
Хоть это мозг не взрывает?
Ну а если вам не важно какой разделитель использовать может лучше :) или :>, я бы предложил еще %)
Так это проблема интерпретатора, то, что он не умеет нормально разбирать контексты. Сам язык от этого не пострадает, я имею ввиду легкость чтения программ, вероятность случайной ошибки и сложность ее нахождения. Скорее наоборот: наличие единого символа для однотипных действий будет только плюсом.
Как в питоне символ "." можно понимать как «вход в объект / доступ к подобъектам». Например:
пакет1 . модуль2 — доступ к модулю2 из пакета1,
модуль2 . класс3 — класс3 из модуля2
объект5 . метод8 — метод8 из объекта5 (причем не важно, обычный это метод, статический или классовый)
Все очень наглядно и понятно. Запутаться невозможно.
А то такими темпами дойдем до перла, где обращение к хешу возможно двумя вариантами — отличная возможность для создания ошибок и долгих ночей дебага.
Как в питоне символ "." можно понимать как «вход в объект / доступ к подобъектам». Например:
пакет1 . модуль2 — доступ к модулю2 из пакета1,
модуль2 . класс3 — класс3 из модуля2
объект5 . метод8 — метод8 из объекта5 (причем не важно, обычный это метод, статический или классовый)
Все очень наглядно и понятно. Запутаться невозможно.
А то такими темпами дойдем до перла, где обращение к хешу возможно двумя вариантами — отличная возможность для создания ошибок и долгих ночей дебага.
Как я понимаю, камень преткновения в php — функции-сироты внутри пространства имен. В руби или в джаве невозможно держать функцию в пространстве имен без класса (или хотя бы модуля, в руби).
Поэтому Foo::bar() там имеет только один смысл.
Нет времени читать их обсуждение, но они рассматривали возможность отказаться от бесхозных функций в неглобальном пространтстве имен? куча проблем бы отпала.
Поэтому Foo::bar() там имеет только один смысл.
Нет времени читать их обсуждение, но они рассматривали возможность отказаться от бесхозных функций в неглобальном пространтстве имен? куча проблем бы отпала.
Да эта страшная проблема, для каждой операции обязательно нужен свой символ :D
Так и до смайликов недалеко
Так и до смайликов недалеко
// separator.cpp
#include <stdio.h>
namespace space
{
void printf(const char * text)
{
::printf(text);
}
}
class Class
{
public:
static void printf(const char * text)
{
::printf(text);
}
};
int main()
{
::printf("global\n");
space::printf("space\n");
Class::printf("class\n");
return 0;
}
$ g++ separator.cpp -o separator && ./separator
global
space
class
После таких вещей всё больше хочется перейти на Python.
За питоном будущее.
За питоном настоящее, будущее за Ruby, Smalltalk и IO.
Будущее будет тормозить?
Ну тогда уж за Haskell-ем будущее :-)
Pure Functional не пройдут. Хотя идеи из Haskell&Erlang черпать будем, но вот ОО-модель куда более подходит для большинства вещей и привычна большинству разработчиков. У гибридов Scala/F# шансов побольше, но всё равно они слишком сложны и непривычны для большинства разработчиков.
Вообще код на функциональных/динамических языках всего раза в 2 короче аналогов на C#/Java, так что с них мы вряд ли куда либо уйдём. А существующие задачи они вполне себе решают.
Вообще код на функциональных/динамических языках всего раза в 2 короче аналогов на C#/Java, так что с них мы вряд ли куда либо уйдём. А существующие задачи они вполне себе решают.
не тревожьте тушку смалтолка. от того, что мы будем безконца вспоминать его прелести — он всё-равно не оживёт.
Lisp жил, Lisp живет, Lisp будет жить.
А какой ваш любимый php редактор? Чтобы был лучше «какой-нибудь» зенд студио?
Мне больше понравился вариант ^^ или :) как раз в духе php
Мда, если посмотреть на список вариантов из которых они выбирали:
то становится понятно что это не самый худший. Хотя, было бы интересно смотреть на что-то типа:
MyCMS:)Stuff:)Cache
\ ** ^^ %% :> :) :::,то становится понятно что это не самый худший. Хотя, было бы интересно смотреть на что-то типа:
MyCMS:)Stuff:)Cache
Если не брать представление что это смайл, то было бы неплохо с таким символом :>
System:>Auth:>Check
System:>Auth:>Check
Точка — это конкатенация строк
Да, конечно точка была бы намного логичнее. Но её не используешь, увы — получается много неоднозначностей.
Еще неплохо бы вышлядела такая констукция: ~>
Еще неплохо бы вышлядела такая констукция: ~>
При написании кода совсем неудобно набирать ~> не снижая темпа.
почему же «$obj->prop» вам удобно набирать, а «Name~>Name2» нет?
расположение ~ не очень удобно…
Ну я и $obj->prop не набираю, я набираю obj.prop. А если и сравнивать 2 эти варианта, то они отличаются только знаками — и ~. Так вот набрать на клавиатуре — намного проще чем ~ т. к. одной левой рукой нажимать Shift и ~ это еще как выкрутиться надо. Конечно возможно кто-то пользуется в таких случаях правым шифтом, но я таких случаев не встречал. Ну и возможно кнопка ~ на некоторых клавах может находиться в другом месте.
какие например неоднозначноcти? хоть одну назовите?
просто видимо афторы этого поделья добавить использование точки не могут.
просто видимо афторы этого поделья добавить использование точки не могут.
а чо, символ точки как разделитель имен не осилили сделать :)
хмм… в уже на радостях от 5.3alpha2 написал куча кода, в ожидании «stable release in October»
когда же удалял все not namespaced функции из ядра PHP
распихав по всяким Array, String, SPL, HTTP…
для совместимости можно налепить «кучу» прокладок, от новых NS к глобальным функциям.
глобальное пространство имен будет очишено он не логичных имен
будет медляно работать, но то кто хочет быть «на гребне волны» — быстренько код перепишут.
вообщем скрестив пальцы ждем php6 (:
распихав по всяким Array, String, SPL, HTTP…
для совместимости можно налепить «кучу» прокладок, от новых NS к глобальным функциям.
глобальное пространство имен будет очишено он не логичных имен
будет медляно работать, но то кто хочет быть «на гребне волны» — быстренько код перепишут.
вообщем скрестив пальцы ждем php6 (:
а есть default namespace?
дополнительно к предложенному вами распихиванию можно засунуть/продублировать все старые функции в namespace Obsolete :)
дополнительно к предложенному вами распихиванию можно засунуть/продублировать все старые функции в namespace Obsolete :)
канечно же есть, без имени.
имхо 6я версия это как раз повод навести порядок, «положив» на совместимость вниз. (:
имхо 6я версия это как раз повод навести порядок, «положив» на совместимость вниз. (:
я имел в виду назначать namespace для своей программы, что-то вроде
пардон, но тогда не понял вопроса (: можно пример?
Кстати небольшиен подвижки уже есть в этом направлении
wiki.php.net/rfc/namespaces-for-internal-classes
wiki.php.net/rfc/namespaces-for-internal-classes
Немного некрасиво, конечно, но в целом ничего криминального нет.
Понятно что разделитель "::" создает проблемы с неоднозначностью, но аргументировать новое решение вот этим:
как то не серьезно…
Преимуществом такого подхода по мнению разработчиков патча является то, что \используется\для\разделения\элементов\пути в Windows и потому будет интуитивно понятным для программистов из мира Windows
как то не серьезно…
да это вообще на аргумент не похоже.
Если быть точным, то это один из аргументов
\this\is\used for paths on Windows and is intuitively familiar to those developers. According to a php|arch survey (as relayed by Steph Fox), most of their readers develop on Windows and deploy on Unix, which would imply that \these\paths are familiar
\this\maps\to\filesystem layouts often used by autoload intuitively for the above reason
По моему, читабельность падает в разы из-за \
Красиво было бы с символом |
Хм, одиночное двоеточие использовать было, видимо, не судьба.
Не знаю в c++ :: — не мешает некому :)
А символ / — в namespaces-ах это жесть :)
IMHO
А символ / — в namespaces-ах это жесть :)
IMHO
Интересно почему / не решили. Это же самый прямой способ получить простой autoload
как же любят обсуждать и придумывать постфактом.
данный вопрос обсуждался ещё до появления namespace, тогда приняли решение использовать :: так как не нашли веских аргументов против. так нет же, как только сделали, народ вдруг вспомнил, что надо бы подаать советов разработчикам.
p.s. я вижу другую причину отказа от :: которой как раз не было на момент создания namespace, но чтобы не подбрасывать огоньку промолчу. а то приведённые причины смехотворны.
данный вопрос обсуждался ещё до появления namespace, тогда приняли решение использовать :: так как не нашли веских аргументов против. так нет же, как только сделали, народ вдруг вспомнил, что надо бы подаать советов разработчикам.
p.s. я вижу другую причину отказа от :: которой как раз не было на момент создания namespace, но чтобы не подбрасывать огоньку промолчу. а то приведённые причины смехотворны.
p.s. я вижу другую причину отказа от :: которой как раз не было на момент создания namespace, но чтобы не подбрасывать огоньку промолчу. а то приведённые причины смехотворны.
microsoft? ;)
Что значит «постфактум»? Релиза еще не было как бы. Кто пользовался — как я, например — пользовался на свой страх и риск. А причина «удалить неоднозначность» вполне себе веская. А что насчет «так нет же, как только сделали, народ вдруг вспомнил» — так это, знаете, всегда и влюбом деле так, тем более в таком сложном, как проектирование языка программирования, которым пользуются миллионы: пока не начнется более-менее массовое тестирование, возможно найти серьезные огрехи и/или пробелы в проектировании.
Сегодня эволюция требует адекватного namespace. Завтра появится еще что-нибудь. Ждем разделителей типа ^% ()!!! и т. д. почему в том же С++ нормально живет :: в неймспейсах, а в пхп — нет? Выше писали про статические функции, в C++ нет статических функций (не особый знаток C++, но как я слышал, есть они там).
ИМХО, девелоперы пытаются навернут на существующую платформу новые возможности за счет удобства.
ИМХО, если делать синтаксис, подобный С-языкам — то продолжать и поддерживать привычные программисту конструкции. Лично я, встретив в тексте программы что-то типа \Exception, врядли бы разобрался б, что имеется в виду…
Да, насколько знаю, в python обходятся без namespaces и нормально поживают… А в пхп они бы очень не помешали… но опять же, ИМХО, не в ущерб юзабилити языка и читаемости кода.
ИМХО, девелоперы пытаются навернут на существующую платформу новые возможности за счет удобства.
ИМХО, если делать синтаксис, подобный С-языкам — то продолжать и поддерживать привычные программисту конструкции. Лично я, встретив в тексте программы что-то типа \Exception, врядли бы разобрался б, что имеется в виду…
Да, насколько знаю, в python обходятся без namespaces и нормально поживают… А в пхп они бы очень не помешали… но опять же, ИМХО, не в ущерб юзабилити языка и читаемости кода.
Я бы лучше занялся обсуждением проблеммы отсуцтвия многопоточности.
У разрабов всё же хватило разума не лезть ещё и туда) Возьмите более подходящий для этого язык, если вам это действительно надо: Java/Erlang.
шутите чтоли, если бы было так просто добавить ее — многопоточность давно бы уже была.
и как юзать ctrl + f при таком подходе не ясно
Самое смешное, что знак адреса @ уже используется для поедания сообщений об ошибках, а ведь он был бы более кстати в адресации неймспейсов.
А вот для поедания прекрасно подошло бы 8()
(-:
$err = new @PEAR2@MultiErrors;А вот для поедания прекрасно подошло бы 8()
$wp = 8() @fopen($dest_file, "wb");(-:
Кракозяберность на марше.
Это ужасное решение. Сивол бэкслеша \ ненагляден и не читается. Разделитель должен быть всегда меньше основніх символов. Имхо он на себе очень тормозит чтение кода.
Использовали б уже
Namespace##Class
Namespace%%Class
я не знаю, имхо поспешное решение совершенно.
Использовали б уже
Namespace##Class
Namespace%%Class
я не знаю, имхо поспешное решение совершенно.
Спорное и некрасивое решение. особенно с учетом аргументов про \Windows\.
Они просто убивают PHP.
Microsoft им денег дал.
Если \ это примут то я
Выкну PHP со своей тачки!
Microsoft им денег дал.
Если \ это примут то я
Выкну PHP со своей тачки!
Недавно видел видео с какой-то конференции где одному из девелоперов пхп был задан вопрос когда мы сможем при вызове вызове функции, возвращающей массив, сразу писать квадратные скобки без необходимости сохранять этот массив в переменную. На что этот девелопер ответил «А оно вам надо?!»
Так что, имхо, пхп идет в абсолютно непонятное «светлое будущее» и 6-ая версия будет переломной точкой, когда много людей его покинут…
Так что, имхо, пхп идет в абсолютно непонятное «светлое будущее» и 6-ая версия будет переломной точкой, когда много людей его покинут…
Это будет подарок для Python и Ruby
Как Vista была подарком для Linux и Mac
Как Vista была подарком для Linux и Mac
И правильно сказал! Единственный случай, где «тянет» так обратиться к массиву, это при использовании explode(). И то только от ленности и никак не улучшает, а только ухудшает чтение кода после вас. В остальном таких позывов не появляется.
Имхо, довольно частая операция:
Может не используете потому что нету?
php > function foo() { return array('bar' => 'hello'); }
php > echo foo()['bar'];
Parse error: syntax error, unexpected '[', expecting ',' or ';' in php shell code on line 1
php > $foo = foo();
php > echo $foo['bar'];
hello
Может не используете потому что нету?
Образчик абсолютно надуманного примера. Если вы возвращаете одно значение, то зачем в виде массива? Если возвращаете несколько значений в массиве, то предполагается использование их всех.
Я уже дал вам подсказку (наверно единственный случай), когда из массива значений мочет понадобиться только одно — explode().
Я уже дал вам подсказку (наверно единственный случай), когда из массива значений мочет понадобиться только одно — explode().
Я программирую на javascript’е не меньше чем на пхп и в нем есть много сахара, который позволяет программировать так, как мне хочется, а не думать надо ли мне это или можно обойтись аскетизмом чистого С.
По поводу explode, если это была подсказка то она была мне, а не SergeyKish :) В случае числовых индексов, соответствующих позициям элементов, мы можем сделать array_slice и потом присвоить в list. В остальных случаях без переменной не обойтись. Хорошо ли это? Я думаю что нет…
Вообще, мое глубокой убеждение что чем больше сахара тем лучше. Единственное что надо следить, чтобы весь сахар был в едином стиле и чтобы не плодились лишние символы, которые используются всего несколько раз.
По поводу explode, если это была подсказка то она была мне, а не SergeyKish :) В случае числовых индексов, соответствующих позициям элементов, мы можем сделать array_slice и потом присвоить в list. В остальных случаях без переменной не обойтись. Хорошо ли это? Я думаю что нет…
Вообще, мое глубокой убеждение что чем больше сахара тем лучше. Единственное что надо следить, чтобы весь сахар был в едином стиле и чтобы не плодились лишние символы, которые используются всего несколько раз.
Думать надо. Конечно множество значений!
Не занимайтесь буквоедством — зачем еще использовать массив? Может вам десяток значений написать чтоб понятнее было?
Если возвращается массив то возможно это generic, ага.
И вы считаете это удобным?
Из-за таких как вы пхп такой какой он есть.
Не занимайтесь буквоедством — зачем еще использовать массив? Может вам десяток значений написать чтоб понятнее было?
Если возвращается массив то возможно это generic, ага.
# Этот метод лежит где-то. Предупреждая ваши вопросы - он очень сложный и возвращает кучу полей
php > function foo() { return array('bar' => 'hello', 'zzz' => 'some'); }
# Но нам нуждно одно поле! Одно!
# Например, это 'bar'
php > function fooBar() { $foo = foo(); return $foo['bar']; }
php > echo fooBar();
# А можно еще так
# И вновь предупреждая буквоедство - рассматриваем вариант в котором из одной выборки необходимо одно значение
php > function fooField($field) { $foo = foo(); return $foo[$field]; }
php > echo fooField('bar');
hello
И вы считаете это удобным?
Из-за таких как вы пхп такой какой он есть.
Я хотел вам сказать, что в _реальной_ жизни не надо генерировать массив с опупенным количеством элементов, что бы взять из него только одно. Если такое надо, то так получается, что для этого существую другие альтернативы. Например:
fstat() -vs- filectime(), filemtime() и т. п.
fstat() -vs- filectime(), filemtime() и т. п.
разработчики библиотеки могут предполагать всё, что угодно, а вот решать что использовать, а что нет, решает приложние. случай с explode — яркий тому пример.
Преимуществом такого подхода по мнению разработчиков патча является то, что \используется\для\разделения\элементов\пути в Windows и потому будет интуитивно понятным для программистов из мира Windows (По результатам опроса большинство читателей php|architect ведут раработку на Windows, а на Unix лишь деплоят работу :-)).
а программисты из мира никсов уже не в счет?
и что делать с escape, совершенно непонятно… опять ряды бэкслэшей, как в неудачных регексах в джаве?..
да и зачем придумывать велосипед, когда все, кому надо, умеют работать с ::?
не хочу никого обидеть, но почему-то возникает впечатление, что мол вот, программисты на пхп не умеют отличить одно :: от другого…
вобще не в тему имхо затеяли с этими неймспейсами в пхп5.3, дождались бы нового движка в пхп6 и реализовали бы по-человечески. Потому что на данный момент уже наработаны решения проблемы неймспейсов путём использования конвенции об именовании классов через подчёркивания (типо класс «Zend_Db_Table» в файле "./Zend/Db/Table.php") с соответствующим автолоадом. А когда прикрутят новые неймспейсы, обязательно начнётся смешение нынешнего и нового подходов и будет каша.
плохо будет и с "::" и с "\". вобщем очень спорный вопрос нужны ли сейчас вобще неймспейсы. пхп реально очень не хватает чего-то вроде PEP или JSR.
к вопросу об IDE для пхп — сейчас имхо стоит обратить внимание на NetBeans 6.5. Поддержка уже сейчас классная, плюс динамика её развития просто бешеная (это ко всему нб относится)
плохо будет и с "::" и с "\". вобщем очень спорный вопрос нужны ли сейчас вобще неймспейсы. пхп реально очень не хватает чего-то вроде PEP или JSR.
к вопросу об IDE для пхп — сейчас имхо стоит обратить внимание на NetBeans 6.5. Поддержка уже сейчас классная, плюс динамика её развития просто бешеная (это ко всему нб относится)
Как то походу почти всем ненравится эта идея с бэкслешем, и мне тоже. Зачем издеватся над людьми? Помоему :: вполне привычно и т. п.
Почему не ::
и что я тут вызвал? функцию Bar() NS Foo или статический метод Bar() класса Foo?
Foo::Bar()
и что я тут вызвал? функцию Bar() NS Foo или статический метод Bar() класса Foo?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разделитель в пространствах имен в PHP