+1. Maybe PHP 6, as Sebastian suggested.
David
Am 05.12.2007 um 19:22 schrieb Jochem Maas:
+1 for putting namespaces on the backburner and taking the time to
get it 100% right ...
Stanislav Malyshev wrote:
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.
Yes, idea of namespaces is not to turn PHP classes into a pile of
goo.
But what's your point?
I don't quite understand why allowing multiple namespaces is such a
big issue, however - it won't solve the naming collision issue.
I'm sorry, I don't understand what you mean by "multiple
namespaces" -
multiple namespaces per file? I object to allowing it for reasons
having
absolutely nothing to do with naming collisions, as anybody
bothering to
actually read what I wrote would immediately know.
this implies that your objections to multiple namespaces per file is
valid
whereas objections to the limitation are invalid.
apparently people keep 'flogging this horse to death' because they
are not
convinced by your wisdom with regard to this decision - they may be
idiots (me included)
but they are the majority of your users, so it seems.
That's because namespaces are not executable blocks.
Neither are classes.
Your point being?
that therefore your argue that "namespaces are not executable
blocks" doesn't
hold up unless your willing to state the inconsistency is one of
your design goals.
No, but, do you really need to have such long names? And besides
that,
Yes. Such names are hard fact of life, I have seen them in many
applications and libraries, and I have heard developers to complain
about it.
<remark type="OT" class="irrelevant">
developers will complain, it's in their blood, nothing anyone will
ever produce
will change that ... somewhere in the future when all code is
created without the
intervention of man .. even then there will still be a compiler
complaining.
</remark>
you *have* to keep repeating them in every file you'd want to use
them -
Once per file, yes. Much better than having to spell out all the long
names every time.
Just saying "Yes, they are" is not a very good argument -
actually, it's
not an argument at all.
No more and no less than "I wonder if they are useful, let's just
delete
them".
actually that is not true - a halfbaked concept is pretty much
garanteed to give you
and the users of your product more headaches than no implementation
at all. and
once the genie is out of the bottle your stuck with it - with all
the BC implications
of having to support functionality people would rather see changed.
besides possibly having to type a little less, there seems to be
nothing namespaces would
give us [in it's current form] that we cannot achieve already ...
with the bonus that
users are currently not restricted in the way they organize/rollout
their code, at least
with regard to 'bundling' of files.
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).
Of course, if you don't want to hear about namespaces, nobody can
force
you. However, all of your points (avoiding naming collisions, not
needing to import every class you want to use and ability to group
classes together) is exactly how namespaces work right now. If you
refuse to learn about it, it can't be helped, however that just means
you deny yourself a very useful tool.
conversly - when namespace functionality is released, every
developer will be confronted
with any problems they might bring with them, at some stage, because
there will be third
party code out there that uses namespaces (code which for the sake
of argument one would
be required to use under some circumstances).
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
David Zülke
[EMAIL PROTECTED]
Tel: +49 (0)89 57 08 15 15
bitXtender GbR
Paul-Heyse-Straße 6
80336 München
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
