[PATCH] Namespace Patch, Beta 1

[whirlwind]

Блин, читал, читал... Так нифига и не понял, накой эта пятая нога, когда я не могу получить элементарно

$this->MyClass::MyMethod()

 

[tony2001]

ты не в теме.

 

[whirlwind]

Че не в теме то? Объясни зачем придумывать новую фичу, если нельзя полностью контролировать те пространства, без которых кода быть не может? Объявление класса, функции, программного блока - это не определение нового неймспейса? Или я действительно не в теме?

 

[tony2001]

ты не в теме.

 

[BeGe]

Ну и ....

$this->MyClass::MyMethod()

Синтаксис проверь =)

 

[whirlwind]

class A{
	public function foo(){
		echo "A\n";
	}
}

class B extends A{
	public function foo(){
		echo "B\n";
	}
}

class C extends B{
	public function foo(){
		echo "C\n";
		parent::foo();
		//$this->A::foo();
	}
}

$o = new C;
$o->foo();

PS. Еще расскажите, что неймспейсы это разработчики php придумали.

 

[tony2001]

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

 

[whirlwind]

ЗЫ. т.к. на ПМ я ответ не получил, делаю вывод, что я все-таки в теме.

Речь о

<?php
namespace Math {

class Complex {
//...код...
function __construct() {
print("привет");
}
}
}

Пример практического применения: создание одноимённых классов в разных именных пространствах; при этом классы делают отличную друг от друга работу (имея одинаковый интерфейс).

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

Давайте взглянем, какой гемморой мы имеем из-за ущербной реализации неймспейса сейчас. Во-первых, мы ограниченны предыдущим классом в иерархии. Именно это и не позволяет реализовать наследника, который будет представлять "другой неймспейс" представляющий класс Complex из примера. Во-вторых, благодаря тому, что недоступно разрешение имени вида Class::Method, для того что бы вызвать базовый метод с переменным числом аргументов нужно сильно изголиться с методом call_user_func. Вместо передачи $this и логичного "Class:Method" мы вынуждены передавать незнамо что. И где такое есть, что без неймспейсов невозможно

при этом классы делают отличную друг от друга работу (имея одинаковый интерфейс)

Именно для процитированного "такие неймспейсы" в языке поддерживающем ООП как раз таки и не нужны. Более того, они там мешают, потому ломают привычную схему проектирования. Ничего хорошего от ухода от стандартов и привычных методов ждать не приходится. Примеров тому масса (и что это вообще за ключевое слово, прям коробит, global?).

В лучшем случае, получаем припарку, которая решает проблему кривой реализации неймспейса (имеется в виду нормальный неймспейс, а не то что там обозвали за фичу). И.г. проблемы нормальной реализации будут скрыты за счет внешней обертки. При этом внутренние проблемы решены не будут. И к этому не забудьте добавить гемморой за счет наложение ограничений как по именам функций, так и на синтаксис, который перегружается за счет новых конструкций. Вот в теме спор идет - какой символ юзать, да такой же как и везде. Просто сделать нормальный неймспейс не на уровне фичи, а как положено, как везде.

-~{}~ 12.12.05 14:51:

А вот здесь продолжение выявлений различныйх геммороев, в случае рассмотрения неймспейса в качестве фичи http://phpclub.ru/talk/showthread.php?postid=554486#post554486

Хотя все прозрачно, если рассматривать начиная с глобального пространства имен.