true namespaces, yet another point of view View as Markdown

For those that do not understand very well the explanation of jvlad...

Guileherme, you are missing the point. We'd all like to see PHP 5.3.0 out
there. It has a lot to offer, but namespace support is very obviously
problematic. That's it, that's all.

• Steph

""Guilherme Blanco"" guilhermeblanco@gmail.com wrote in message
news:bcb7aa500809231617y3305b5bcn18f47630a8124e0d@mail.gmail.com...

For those that do not understand very well the explanation of jvlad...

He's suggesting to change the class struct to be an scope struct, and
have a property that tells if it's a namespace or a class, and reuse
the implementation of class which already works very well.
The nested support is achieved afai understand through the Adjacency
List algorithm... can you confirm this to me?

Just trying to be more clear to those that do not understand... if my
words are greek now.... GIYF (Google Is Your Friend).

Yep. Thanks Guilherme for such a short explanation.
(sorry my english is quite poor and not always clear enough)

Namespaces create ambiguity with classes in php (which is a dynamic language
btw) just because their natures are very close. Beside the other great
things, class is intended to isolate its methods and properties, or group
them together. Namespace is mostly for the same purposes. It should isolate
classes as well as all other user-land entities or group them together. From
the end-user perspectives, in most cases it does not really matter if a
particular value is stored as a static property of a class or as a global
variable in a namespace. Same goes for the static method of a class vs
function in the namespace. What's important is to know the scope name. If
user uses a variable myentity::$var, it's safficient to lookup for myentity
sub-scope in the current scope, then lookup for $var in the found (or just
created) sub-scope. You see, it's not always needed to distinguish classes
vs namespaces.

In some cases the namespace can be resolved in the compile-time. For example
if the namespace is already defined, so it's known to be namespace and
therefore compiler should be smart enough to make early binding. For the
cases when namespace is referenced in the script beforehand, so it's not
known whether it is a namespace or a class, it can be resolved with
late-binding, using absolutely the same technique as php uses for for
resolving the classes.

I'm sure this is an efficient way of implementing namespaces in php and with
this implementation they will be very useful.

jv

For those that do not understand very well the explanation of jvlad...

He's suggesting to change the class struct to be an scope struct, and
have a property that tells if it's a namespace or a class, and reuse
the implementation of class which already works very well.
The nested support is achieved afai understand through the Adjacency
List algorithm... can you confirm this to me?

or just leave the organization of things to classes (with long class
names with a nice prefix to prevent collissions) and leave it to
class_alias() (and equivalent features for functions .. also with the
option of a compile time aliasing) to handle the aliasing.

this removes the need for namespaces and use statements, while making
it possible to make class/function names short (that are long for
organizational and collision prevention reasons).

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

I completely agree with jvlad's thoughts - for me namespace is ability to
separate two different libraries from each other so that they don't
conflict. I don't need namespaces just to write my own application using
them to be cool, and I probably would never use a namespace for small or
middle size application, but what I will surely do - namespace libraries
witch I will use in my application, so that I don't have to use prefixes for
my application functions and classes.

AndIMHO, I really don't want to remember those complicated rules for
name resolution, importing namespaces. There is category of developers,
witch will make a real mess of this. As I personally see namespaces:

index.php

<?php
require_once('application.php');

namespace Zend {
require_once('zendframework.php');
}

namespace PDF {
require_once('tcpdf.php');
}

$loader = new Zend::ZendLoader();
$db = new Zend::ZendDB();
$pdf = new PDF::TCPDF();
$application = new Application();
$application->addHandler('loader', $loader);
$application->addHandler('db', $db);
$application->addHandler('pdf', $pdf);
$application->run();
$application->quit();
?>

Of course that isn't a good example, because Zend framework always has a
class prefix "Zend", but they surely can use a namespace and remove that
Zend in front of classes.

And I don't see any point in "use NamespaceName as OtherName" - I open a
project, there is namespace Foo used for libraries. Then I open some modules

• there is Bar::get() in the code. What will I look for? Namespace Bar,
  especialy when many namespaces are used in application. imporing foo as bar
  is quite confusing. Yes, we programmers can handle such things, we can learn
  from our mistakes, but that's not the reason to make us masochist! I'm
  fed-up with teaching people all the time how to properly code in PHP or
  clean the code after such people. Really, sometimes PHP core developers
  should say to comunity "f*k you, we will do that the proper way" and just
  do. People are happy with Java, .NET and so on and nobody is complaining
  that they can't import namespace under other name than original (maybe in
  some languages you can do that, but I don't code much in other languages, so
  I can't say that for sure). This is called "standarts" - everybody knows
  that name "Foo" always means "Foo" if "Foo" package is used in application,
  and that nobody can import it as "Blah" - they will have to change the
  namespace in package itself and that's so stupid , that nobody will do that
  (well if they do - don't mess with such people at all).