On Tue, 4 Dec 2007, Stanislav Malyshev wrote:
> > following some discussions on the list (re. multiple namespaces in file) as
> > well as a short discussion on IRC regarding not being able to do
> > "use yeti::xml::DomDocument as DomDocument;" - I do not see any point in
> > having
>
> You mean like ability to override existing classes? I think it could be done
> but I don't see it as a good idea - it probably would lead to some weird
> programming mistakes.
Of course, I think allowwing this is a really bad idea - which brings me
to the main point of this argument:
> > > 1. As it is impossible to do "use XXX as NativeClass" we get to the
> > > point
> > where we'd have to namespace new internal native classes
> > otherwise we might introduce BC breaks. AFAIK, we've always said that
>
> There's very easy solution to this, if it ever becomes a problem - using
> two-component names.
And that is exactly what I think we should not do. PHP reserves the
global scope. period. That means that (core)extensions should not have
to deal with all sorts of namespace clue or other tricks just because
some people like a "misguided" implementation of namespaces. The idea of
namespaces is to prevent collisions in USER land code, not turning
internal PHP classes into a pile of goo.
> > 3. We keep bickering over using { } or not, multiple namespaces in a
> > file or not... etc. I understand that people want more flexibility,
> > but also we need a *simple* to explain implementation. With the
>
> That's why not all flexibility gets in.
>
> > - You can't stick multiple namespaces in one file
>
> You are not supposed to unless you using it as performance solution, which is
> rather dubious practice anyway.
You're not supposed to put a count($array) inside your for loop either.
I don't quite understand why allowing multiple namespaces is such a big
issue, however - it won't solve the naming collision issue.
> > - Unlike other constructs in PHP that mark executable blocks,
> > namespaces don't use { }.
>
> That's because namespaces are not executable blocks.
Neither are classes.
> > 4. What is wrong with simple prefixes in the first place? Both PEAR_*,
> > Zend_*, ezc*, and ezp* are perfectly acceptable markers for different
> > 'namespaces'. We could optionally create a registry on php.net for
> > this to avoid conflicts.
>
> What is wrong is names like
> PEAR_DB_Data_Database_Module_Adapter_Implementation_Interface_Exception_Information_Collection_Element.
> When you write a code that uses such names, you really don't want to repeat
> all the thing every time.
No, but, do you really need to have such long names? And besides that,
you *have* to keep repeating them in every file you'd want to use them -
which means you actually have to type *more* in some places. So this
argument is kind of lame.
> > useful - or what particular case they solve... so I am wondering, are they
> > really useful? I come now to the conclusion that they are not, and for
> > myself
>
> Yes, they are.
Just saying "Yes, they are" is not a very good argument - actually, it's
not an argument at all.
> > (and most likely my work projects) I would have to decide not to go with
> > namespaces, but instead stick with the 3 letter prefixing. Something that I
>
> Well, the loss is all yours :)
Actually, it's exactly the opposite, as I avoid naming colissions
(point 1), I don't need to import every class I want to use (point 2),
and can group all my classes together in one file (point 3).
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
