hi Dmirty,
I really don't see a reason to change namespace syntax into a less
intuitive way.
I don't think the current implementation is intuitive, the ambiguity
issues,
(and possibly the name resolution order, although I can't grok what the
current
state of that is) are rather large WTFs.
Your speed degradation argument isn't truth. The
ambiguity problem exists, but it is just an ability to use php in a
wrong way. Just don't create conflicting names.
which begs the question, what was namespaces created for?
(that's a serious question because your statement has me truly confused)
you didn't answer the question (and AFAIC the readme doesn't either).
The main reason of namespaces is resolution of name conflicts and
ability to use the same names in different scopes.
thank you for confirming this explicitly.
README.namespaces was committed into PHP_5_3 about year ago.
a 14 month old document which doesn't cover the status quo,
and begins with a disingenuous statement about the problem namespaces
try to
solve (is that really all there is to namespaces? to avoid typing long
class names?
Yes, you are right. It's need to be adopted to current situation which
might be changed once again...
okay :-) ... I did actually promise Lukas that I'd write a
guideline/best-practices
doc regarding namespaces ... I still intend to give that a shot, It will require
that people like you and Stas (amongst others) give a little time to vet the
doc for accuracy, do you see this as a problem?
most people have auto-complete features in their editor to take care of
that 'problem'
and it really doesn't explain why constants or functions exist in
namespaces at all.)
I see you point, and you might be satisfied with decision which is going
to be final, however from my point of view function and constants must
be allowed in namesapaces just because they are parts of the language.
I would prefer to have functions and constants in namespaces, but I think the
current implementation requires greg's patch in order to make it work.
additionally I think autoloading for functions (and actually anything namespace
related) should be seriously considered. the fact that it's only classes that
can
be autoloaded and namespaced is of itself consistent. there is something to be
said
for this kind of clearly defined 'limitation' - you know where you are!
that said I think dropping functions (and constants) is the only real
alternative
to allowing greg's patch. dropping them may mean an incomplete namespace
implementation,
but in this case it's a good thing ... it allows people to start using
namespaces
and allows you (php devs) to work out a means to solve the ambiguity issues
surrounding NS funcs/constants without worrying (as much?) about BC issues and
without a barrage of 'wtf' type bug reports and questions (users will
push namespaces to the edge and beyond if you give them the chance, not
introducing funcs/constants means they can't simply can't do certain things for
now)
in the long run functions and constants will be added to namespaces ... and then
the ambiguity issues will have to be dealt with. I believe Greg's namespace
member
concept will be required even if the syntax is/must/should/will changed to
something everyone finds acceptable.
rgds,
Jochem
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
