Hello all,
A number of factors have come together to prompt me to possibly commit
mailing-list-suicide by re-opening the namespace issue.
Last week at Zendcon, a number of PHP developers/community members
chatted about namespaces in PHP 6. That chat was the prime motivator for
this email, but the recent (be they misguided) complaints about symbol
collisions in DateTime, as well as blog entries such as Jeff Moore's on
maintainability [1].
None of us chatting seemed to be able to come up with a good reason we
don't yet have namespaces, other than frustration (the last time we
discussed this, the thread became VERY long and drawn out), indecision
(we couldn't seem to come to a decision on a suitable operator), and
complacency.
The way I see it is that implementing namespaces is a technical hurdle,
and the reasons we haven't jumped it are political, not technical.
So, let's deal with these 3 problems:
Frustration: this thread will likely get long. Please avoid long-winded
explanation of why you don't like the looks of "" or how ":::" is hard
to type. If you have something relevant to say, it's probably already
been said [2][3]. Please review the archives.
Indecision: We couldn't decide on "" or ":::". What this comes down to
is that "" is the only remaining operator that can be typed in a single
keystroke on us_en keyboards. The other choice was ":::". I, for one, am
OK with either operator. I think someone with appropriate (social) karma
needs to simply commit to one or the other, and we'll make do... we
always do.
Complacency: Most of the time, I'm happy to maintain the status quo in
PHP-land. However, the lack of namespaces is causing more trouble than
its absence is preventing. I think most PHP users would agree that
namespaces are a welcome addition, and without them, PHP suffers. Let's
take this in small steps and implement optional userspace namespacing.
There's no need to dive head-first into this and make dramatic moves
like putting all core functions into a PHP namespace. Baby steps, please.
And, in conclusion (thanks for reading this far; I've certainly exceeded
the average non-code-paste post length, a few times over), remember that
the core devs discussed this in Paris, last year [4]. They didn't come
to a conclusion (note the use of "if"), though.
Let's settle this political issue, please, so we can get on to solving
the technical issues that will inevitably crop up.
S
[1]
http://www.procata.com/blog/archives/2006/11/09/why-is-php-code-considered-hard-to-maintain/
[2] http://beeblex.com/lists/index.php/php.internals/20586
[3] http://beeblex.com/lists/index.php/php.internals/17484
[4] http://php.net/~derick/meeting-notes.html#name-spaces
The way I see it is that implementing namespaces is a technical
hurdle,
and the reasons we haven't jumped it are political, not technical.
That's a bit of a circular logic no? There are indeed technical
challenges to implementing namespaces, these reasons have been
covered in previous discussions many times, since no adequate
solution was devised they were never implemented. Once those issues
are resolved or at the very least solutions are known, we can
consider whether or not this is something that's truly needed.
Complacency: Most of the time, I'm happy to maintain the status quo in
PHP-land. However, the lack of namespaces is causing more trouble than
its absence is preventing. I think most PHP users would agree that
namespaces are a welcome addition, and without them, PHP suffers.
Let's
take this in small steps and implement optional userspace namespacing.
There's no need to dive head-first into this and make dramatic moves
like putting all core functions into a PHP namespace. Baby steps,
please.
I think this is a bogus argument. In order to benefit from namespaces
you need to use them, just like to benefit from containment through
prefixing you need to prefix functions/classes/etc... Namespaces are
not a magic bullet that will instantly make your problems go away and
make your code better. If anything it'll make code complex and
intertwined, introduce serious scope issue most people have not had
to consider up until now and so on. It will without a doubt increase
language complexity as well, which generally translates to a loss in
performance.
Ilia Alshanetsky
That's a bit of a circular logic no? There are indeed technical
challenges to implementing namespaces, these reasons have been covered
in previous discussions many times, since no adequate solution was
devised they were never implemented. Once those issues are resolved or
at the very least solutions are known, we can consider whether or not
this is something that's truly needed.
I think we got hung up on political issues. The last discussion was not
technical (other than "no, you can't use ! -- it's already an operator).
I'd love to move onto discussing the technical hurdles, but I don't
think we came to a political conclusion, yet.
I think this is a bogus argument. In order to benefit from namespaces
you need to use them, just like to benefit from containment through
prefixing you need to prefix functions/classes/etc... Namespaces are not
a magic bullet that will instantly make your problems go away and make
your code better. If anything it'll make code complex and intertwined,
introduce serious scope issue most people have not had to consider up
until now and so on. It will without a doubt increase language
complexity as well, which generally translates to a loss in performance.
I don't think namespaces are a magic bullet. As it stands, it's
impossible to use namespaces without a third party patch that may or may
not work. I strongly believe that if namespaces are implemented in PHP
6, most of our prefixing/symbol collisions will go away as people
migrate. It's much easier to track down a failed import than to comment
out a function declaration in the PHP source.
I also don't deny that there will be a minor performance hit. There are
a ton of other things in PHP that reduce performance.. the idea is to
find a balance of which ones are worth it (as we did with OOP and
Unicode), and I believe that namespaces are worth it. I also know that
I'm not alone in this.
S
I don't think namespaces are a magic bullet. As it stands, it's
impossible to use namespaces without a third party patch that may
or may
not work. I strongly believe that if namespaces are implemented in PHP
6, most of our prefixing/symbol collisions will go away as people
migrate. It's much easier to track down a failed import than to
comment
out a function declaration in the PHP source.
PHP 6 is not yet out and probably won't be production quality for
quite some time. Which means that migration to it en mass is probably
not going to happen this decade :-). If we take 5.x adoption as a
benchmark it took it over 2 years to even reach the 10% mark and big
PHP apps still (with good reason) focus on the much larger PHP 4
market. Namespacing core classes/function would be a supremely bad
idea as it could quite literally break every single application. You
also need to consider that until PHP X attains at least 50% or more
market penetration few people would be willing to write applications
that require this version of PHP to work. This is why many of the
projects and companies I am familiar still write new code in PHP 4
rather then in PHP 5, despite that version having numerous perceived
advantages.
I also don't deny that there will be a minor performance hit. There
are
a ton of other things in PHP that reduce performance.. the idea is to
find a balance of which ones are worth it (as we did with OOP and
Unicode), and I believe that namespaces are worth it. I also know that
I'm not alone in this.
I think adoption rates speak for themselves, I think there is far
more demand for a fast & stable PHP then for syntatic sugar features
which seem extremely useful, but in the end prove to carry too much
baggage.
Ilia Alshanetsky
<snippitysnip/>PHP 6 is not yet out and probably won't be production quality for quite
some time. Which means that migration to it en mass is probably not
going to happen this decade :-).
I'm not talking about forcing everyone to use namespaces tomorrow. I'm
trying to plan for a future where there's a sensible way to avoid symbol
collision.
As for everyone developing on PHP $release-1 until 50% market
saturation, I believe that to be the case in widely-distributed PHP apps
(such as FUDForum), but you seem to be forgetting about the large number
of PHP applications that are developed for internal use. I don't know of
anyone currently using PHP 4 to develop new PHP apps unless they're for
external distribution.
I think there is far more
demand for a fast & stable PHP then for syntatic sugar features which
seem extremely useful, but in the end prove to carry too much baggage.
Nothing has been proven either way.. at least not publicly.. unless I
just missed it.
S
<snippitysnip/>PHP 6 is not yet out and probably won't be production quality for
quite
some time. Which means that migration to it en mass is probably not
going to happen this decade :-).I'm not talking about forcing everyone to use namespaces tomorrow. I'm
trying to plan for a future where there's a sensible way to avoid
symbol
collision.
Since day one there was a sensible way to do, prefixing, but for
whatever reason (and let's not get into that discussion) many people
had not which is why we are having this problem today.
As for everyone developing on PHP $release-1 until 50% market
saturation, I believe that to be the case in widely-distributed PHP
apps
(such as FUDForum), but you seem to be forgetting about the large
number
of PHP applications that are developed for internal use. I don't
know of
anyone currently using PHP 4 to develop new PHP apps unless they're
for
external distribution.
I was not referring to just the distributable applications, I know of
many companies and people who develop internal software that's PHP4
only as they have no plans to move to PHP5. There is also a large
number of ISPs providing exclusively PHP4 solutions, which
effectively forces their client base to stick to PHP4. You also
forget that a larger number of PHP developers started their
development by looking at other people's code and using that as a
base. Given that the base is predominantly PHP4 they tend to continue
using PHP4.
Ilia Alshanetsky
I think there is far more
demand for a fast & stable PHP then for syntatic sugar features which
seem extremely useful, but in the end prove to carry too much baggage.Nothing has been proven either way.. at least not publicly.. unless I
just missed it.
I haven't talked to a single developer a large-scale PHP tool,
application, etc. that wouldn't switch their trunk to using namespaces
tomorrow if they were adopted in the engine. We [in] PHP developers who
are building "enterprise" open-source components and frameworks really
will use this feature -- and I think we'd all argue that we really need
this feature. I hope that namespaces would be more than syntactic sugar
-- e.g. providing an import/using keyword that would declare namespace
context -- but even if they were only "syntactic sugar" they would at
minimum provide a naming standard for PHP packages to avoid collisions.
Namespaces certainly got a lot of mention at Int'l PHP Conference (in
form of request and, during the panel, applause from audience when
mentioned); it was clear that this is a very anticipated PHP6 feature.
None of us non-C developers are trying to say we think this should be
easy, or trying to otherwise minimize the problems that have been
presented in the past or the reasons why it hasn't been implemented so
far, but let there be no confusion that this is a really, really
important feature for us.
Thanks,
Hans
Zitat von Hans Lellelid hans@velum.net:
I think there is far more
demand for a fast & stable PHP then for syntatic sugar features which
seem extremely useful, but in the end prove to carry too much baggage.Nothing has been proven either way.. at least not publicly.. unless I
just missed it.I haven't talked to a single developer a large-scale PHP tool,
application, etc. that wouldn't switch their trunk to using namespaces
tomorrow if they were adopted in the engine. We [in] PHP developers who
are building "enterprise" open-source components and frameworks really
will use this feature -- and I think we'd all argue that we really need
this feature. I hope that namespaces would be more than syntactic sugar
-- e.g. providing an import/using keyword that would declare namespace
context -- but even if they were only "syntactic sugar" they would at
minimum provide a naming standard for PHP packages to avoid collisions.Namespaces certainly got a lot of mention at Int'l PHP Conference (in
form of request and, during the panel, applause from audience when
mentioned); it was clear that this is a very anticipated PHP6 feature.
None of us non-C developers are trying to say we think this should be
easy, or trying to otherwise minimize the problems that have been
presented in the past or the reasons why it hasn't been implemented so
far, but let there be no confusion that this is a really, really
important feature for us.
I couldn't agree more. There really wasn't an appealing reason to
switch to PHP5 too quickly for me, and force the users of our code to
do the same. There are a few reasons to switch to 5.2 probably, but
that's a different story.
But if there wasn't already Unicode support in PHP 6, having
namespaces was definitely a good reason to force our user to that
version.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
I am not sure why this thread was revived. We decided long ago that we
would have namespaces in PHP 6 barring any nasty technical problems and
assuming a good way to implement it could be found.
And I'll second Tony here and mention that we really could use more
eyeballs on the bug database. I am sure everyone reading internals has
at least one part of PHP they know really well and it would be extremely
helpful if you could all pick a topic and watch for bugs related to that
topic. It's not hard to see just the bugs you care about. For all the
open Postgresql Related bugs, for example:
Or if you prefer to have them show up in your RSS reader, just put rss
in front of the search.php script there:
Go to http://bugs.php.net/search.php for a list of all the available
categories or even better, just watch for all bugs coming in and attack
the ones you think you might have a clue on.
http://bugs.php.net/rss/search.php?direction=DESC&status=Open&cmd=display
You don't necessarily have to be able to fix them in the C code, just
helping to get rid of bogus reports or translating the really bad
reports into a simple reproducable test case is often the part that
takes the most time. Once we have a 3-5 line reproducing script, the
fix is usually easy.
-Rasmus
Am 11.11.2006 um 14:37 schrieb Rasmus Lerdorf:
I am not sure why this thread was revived. We decided long ago
that we
would have namespaces in PHP 6 barring any nasty technical problems
and
assuming a good way to implement it could be found.
I'm not sure if that was made clear. The meeting notes much rather
say "mmmh okay we'll think about it, and if we like the idea, Marcus
is gonna implement it". I'm glad that was clarified now, thanks :)
David
helping to get rid of bogus reports or translating the really bad
reports into a simple reproducable test case is often the part that
This is a plea for not being quite so bogus-trigger-happy as we have
in the past.
Many correct, if incomplete, bug reports get quickly labeled "bogus"
with no real research, and that only makes it even harder for anybody
to do anything useful...
I know it's [hard] work to wade through those things, to some degree,
but you make your life more miserable with incorrect assessment. :-)
Please do not take this request amiss! It is an attempt, however
small, to make your life better, not to complain about your efforts!
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Richard Lynch wrote:
helping to get rid of bogus reports or translating the really bad
reports into a simple reproducable test case is often the part thatThis is a plea for not being quite so bogus-trigger-happy as we have
in the past.Many correct, if incomplete, bug reports get quickly labeled "bogus"
with no real research, and that only makes it even harder for anybody
to do anything useful...I know it's [hard] work to wade through those things, to some degree,
but you make your life more miserable with incorrect assessment. :-)Please do not take this request amiss! It is an attempt, however
small, to make your life better, not to complain about your efforts!
I think lagging 6-12 months behind on bug reports would be much worse.
If the bug report is incomplete and isn't likely to lead to a resolution
I think it is better to let the reporter know sooner rather than later.
The fact that we only have 2 or 3 people regularly looking at these and
the flow of them is ever increasing doesn't leave us with much choice
here. If more people helped out we could spend more time on each one,
but until that happens, the quick-bogus is going to continue.
-Rasmus
Why not add another bug-status called "incomplete" or something, and append
a standard message saying "Please study the bug-reporting guidelines in
order to write complete and accurate bug reports."? I think this tiny
addition to tagging something "bogus" would make a lot of bug reporters
happier and it might make them fix their bug report.
-- Ron
"Rasmus Lerdorf" rasmus@lerdorf.com schreef in bericht
news:455CB6BD.2080806@lerdorf.com...
Richard Lynch wrote:
helping to get rid of bogus reports or translating the really bad
reports into a simple reproducable test case is often the part thatThis is a plea for not being quite so bogus-trigger-happy as we have
in the past.Many correct, if incomplete, bug reports get quickly labeled "bogus"
with no real research, and that only makes it even harder for anybody
to do anything useful...I know it's [hard] work to wade through those things, to some degree,
but you make your life more miserable with incorrect assessment. :-)Please do not take this request amiss! It is an attempt, however
small, to make your life better, not to complain about your efforts!I think lagging 6-12 months behind on bug reports would be much worse.
If the bug report is incomplete and isn't likely to lead to a resolution
I think it is better to let the reporter know sooner rather than later.
The fact that we only have 2 or 3 people regularly looking at these and
the flow of them is ever increasing doesn't leave us with much choice
here. If more people helped out we could spend more time on each one,
but until that happens, the quick-bogus is going to continue.-Rasmus
Hi,
that's the commonly used (and existing) "Feedback" status, but often
this won't lead to the required feedback.
johannes
Why not add another bug-status called "incomplete" or something, and append
a standard message saying "Please study the bug-reporting guidelines in
order to write complete and accurate bug reports."? I think this tiny
addition to tagging something "bogus" would make a lot of bug reporters
happier and it might make them fix their bug report.-- Ron
"Rasmus Lerdorf" rasmus@lerdorf.com schreef in bericht
news:455CB6BD.2080806@lerdorf.com...Richard Lynch wrote:
helping to get rid of bogus reports or translating the really bad
reports into a simple reproducable test case is often the part thatThis is a plea for not being quite so bogus-trigger-happy as we have
in the past.Many correct, if incomplete, bug reports get quickly labeled "bogus"
with no real research, and that only makes it even harder for anybody
to do anything useful...I know it's [hard] work to wade through those things, to some degree,
but you make your life more miserable with incorrect assessment. :-)Please do not take this request amiss! It is an attempt, however
small, to make your life better, not to complain about your efforts!I think lagging 6-12 months behind on bug reports would be much worse.
If the bug report is incomplete and isn't likely to lead to a resolution
I think it is better to let the reporter know sooner rather than later.
The fact that we only have 2 or 3 people regularly looking at these and
the flow of them is ever increasing doesn't leave us with much choice
here. If more people helped out we could spend more time on each one,
but until that happens, the quick-bogus is going to continue.-Rasmus
Majority of the "bogus" bugs are truly bogus, I see no reason to
change a perfectly valid term used to describe bugs.
Why not add another bug-status called "incomplete" or something,
and append
a standard message saying "Please study the bug-reporting
guidelines in
order to write complete and accurate bug reports."? I think this tiny
addition to tagging something "bogus" would make a lot of bug
reporters
happier and it might make them fix their bug report.-- Ron
"Rasmus Lerdorf" rasmus@lerdorf.com schreef in bericht
news:455CB6BD.2080806@lerdorf.com...Richard Lynch wrote:
helping to get rid of bogus reports or translating the really bad
reports into a simple reproducable test case is often the part thatThis is a plea for not being quite so bogus-trigger-happy as we have
in the past.Many correct, if incomplete, bug reports get quickly labeled "bogus"
with no real research, and that only makes it even harder for
anybody
to do anything useful...I know it's [hard] work to wade through those things, to some
degree,
but you make your life more miserable with incorrect assessment. :-)Please do not take this request amiss! It is an attempt, however
small, to make your life better, not to complain about your efforts!I think lagging 6-12 months behind on bug reports would be much
worse.
If the bug report is incomplete and isn't likely to lead to a
resolution
I think it is better to let the reporter know sooner rather than
later.
The fact that we only have 2 or 3 people regularly looking at
these and
the flow of them is ever increasing doesn't leave us with much choice
here. If more people helped out we could spend more time on each
one,
but until that happens, the quick-bogus is going to continue.-Rasmus
--
Ilia Alshanetsky
Am 10.11.2006 um 19:47 schrieb Hans Lellelid:
I think there is far more
demand for a fast & stable PHP then for syntatic sugar features
which
seem extremely useful, but in the end prove to carry too much
baggage.Nothing has been proven either way.. at least not publicly.. unless I
just missed it.I haven't talked to a single developer a large-scale PHP tool,
application, etc. that wouldn't switch their trunk to using namespaces
tomorrow if they were adopted in the engine. We [in] PHP
developers who
are building "enterprise" open-source components and frameworks really
will use this feature -- and I think we'd all argue that we really
need
this feature. I hope that namespaces would be more than syntactic
sugar
-- e.g. providing an import/using keyword that would declare namespace
context -- but even if they were only "syntactic sugar" they would at
minimum provide a naming standard for PHP packages to avoid
collisions.Namespaces certainly got a lot of mention at Int'l PHP Conference (in
form of request and, during the panel, applause from audience when
mentioned); it was clear that this is a very anticipated PHP6 feature.
None of us non-C developers are trying to say we think this should be
easy, or trying to otherwise minimize the problems that have been
presented in the past or the reasons why it hasn't been implemented so
far, but let there be no confusion that this is a really, really
important feature for us.
Very wall said, Hans, and I totally agree. It's much needed, and I
believe any FOSS project that is OO based would applaud the
introduction of namespaces.
David
I think there is far more
demand for a fast & stable PHP then for syntatic sugar features which
seem extremely useful, but in the end prove to carry too much baggage.Nothing has been proven either way.. at least not publicly.. unless I
just missed it.I haven't talked to a single developer a large-scale PHP tool,
application, etc. that wouldn't switch their trunk to using namespaces
tomorrow if they were adopted in the engine.
You did now then. YOu can't simply switch to using namespaces as you'd
have two branches to maintain that suddendly. Although namespaces would
have helped if it was there from the beginning, we have no problems with
using prefixes at all.
regards,
Derick
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
of PHP applications that are developed for internal use. I don't know
of
anyone currently using PHP 4 to develop new PHP apps unless they're
for
external distribution.
Are you living in a bubble? :-) :-) :-)
There's a zillion ISPs that are not upgrading to 5, and all their
customers are developing new apps in 4.
They may not be big famous super-slick widely-distributed apps, but
they are the "long tail" of your userbase.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
[...]
I also don't deny that there will be a minor performance hit. There are a
ton of other things in PHP that reduce performance.. the idea is to find
a balance of which ones are worth it (as we did with OOP and Unicode),
and I believe that namespaces are worth it. I also know that I'm not
alone in this.
I think adoption rates speak for themselves, I think there is far
more demand for a fast & stable PHP then for syntatic sugar features
which seem extremely useful, but in the end prove to carry too much
baggage.
Escpecially due to the new OO features of PHP 5, namespaces are urgently
required for writers of independent libraries which should not clash. For
me, I even would accept 10% performance loss to have namespaces implemented:
I'd use a faster machine instead, which is cheaper compared to the
adjustment of clashing class names from different libraries or frameworks.
Unfortunately namespaces are not only syntactic sugar, but dire necessity
for PHP if it wants to be taken as a serious langauage and defend it's
position against other arising 'web scripting' alternatives.
But I suppose, you know this.
Just my two cents, regards dtg
Unfortunately namespaces are not only syntactic sugar, but dire necessity
for PHP if it wants to be taken as a serious langauage and defend it's
position against other arising 'web scripting' alternatives.
It seems the list of things that PHP needs to be "taken as a serious
langauage" is never ending. Before PHP 5, all that was needed was good
OOP support. Now this. I am for namespaces, but that line is getting
old and I, a professional, serious PHP developer and tired of hearing it.
--
Brian Moon
http://dealnews.com/
It's good to be cheap =)
Brian Moon wrote:
Unfortunately namespaces are not only syntactic sugar, but dire
necessity
for PHP if it wants to be taken as a serious langauage and defend it's
position against other arising 'web scripting' alternatives.It seems the list of things that PHP needs to be "taken as a serious
langauage" is never ending. Before PHP 5, all that was needed was
good OOP support. Now this. I am for namespaces, but that line is
getting old and I, a professional, serious PHP developer and tired of
hearing it.
I think that one reason why this list is never ending is that these
languages are constantly moving targets -- I would hope that what people
expected of a web development language would evolve over the course of
several years. Daniel's project (coWiki) was one of the first (if not
the absolute first) to show us what was possible with PHP5 and
Exceptions; that was some pretty serious PHP. I think what Daniel means
is that to remain competitive, PHP needs to include the features that
developers have come to expect of a language -- and developers are
constantly changing, maturing, working on bigger & bigger projects,
integrating more & more components. I think PHP has been very
responsive to the needs of the constantly maturing user community,
drastically changing its language to support new & better OOP,
Exceptions, etc. Indeed, this responsiveness to an increasingly OO
userbase is why many of us who started with PHP are still using it
today. Namespaces may be the most fervent request lately, but it would
be very sad for PHP if it were to be the last.
Hans
Hello Hans,
Friday, November 10, 2006, 8:30:55 PM, you wrote:
Brian Moon wrote:
Unfortunately namespaces are not only syntactic sugar, but dire
necessity
for PHP if it wants to be taken as a serious langauage and defend it's
position against other arising 'web scripting' alternatives.It seems the list of things that PHP needs to be "taken as a serious
langauage" is never ending. Before PHP 5, all that was needed was
good OOP support. Now this. I am for namespaces, but that line is
getting old and I, a professional, serious PHP developer and tired of
hearing it.
I think that one reason why this list is never ending is that these
languages are constantly moving targets -- I would hope that what people
expected of a web development language would evolve over the course of
several years. Daniel's project (coWiki) was one of the first (if not
the absolute first) to show us what was possible with PHP5 and
Exceptions; that was some pretty serious PHP. I think what Daniel means
is that to remain competitive, PHP needs to include the features that
developers have come to expect of a language -- and developers are
constantly changing, maturing, working on bigger & bigger projects,
integrating more & more components. I think PHP has been very
responsive to the needs of the constantly maturing user community,
drastically changing its language to support new & better OOP,
Exceptions, etc. Indeed, this responsiveness to an increasingly OO
userbase is why many of us who started with PHP are still using it
today. Namespaces may be the most fervent request lately, but it would
be very sad for PHP if it were to be the last.
Very nice writing, I completley agree. The world is changing, so are
computer languages, so will we... :-)
Best regards,
Marcus
Hello Hans,
Friday, November 10, 2006, 8:30:55 PM, you wrote:
Brian Moon wrote:
Unfortunately namespaces are not only syntactic sugar, but dire
necessity
for PHP if it wants to be taken as a serious langauage and defend it's
position against other arising 'web scripting' alternatives.It seems the list of things that PHP needs to be "taken as a serious
langauage" is never ending. Before PHP 5, all that was needed was
good OOP support. Now this. I am for namespaces, but that line is
getting old and I, a professional, serious PHP developer and tired of
hearing it.I think that one reason why this list is never ending is that these
languages are constantly moving targets -- I would hope that what people
expected of a web development language would evolve over the course of
several years. Daniel's project (coWiki) was one of the first (if not
the absolute first) to show us what was possible with PHP5 and
Exceptions; that was some pretty serious PHP. I think what Daniel means
is that to remain competitive, PHP needs to include the features that
developers have come to expect of a language
Many developers came to PHP in spite of what other developers had come
to expect in other languages.
Cheers,
Rob.
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'
Unfortunately namespaces are not only syntactic sugar, but dire
necessity
for PHP if it wants to be taken as a serious langauage and defend
it's
position against other arising 'web scripting' alternatives.It seems the list of things that PHP needs to be "taken as a serious
langauage" is never ending. Before PHP 5, all that was needed was
good
OOP support. Now this. I am for namespaces, but that line is getting
old and I, a professional, serious PHP developer and tired of hearing
it.
I was tired of it before the OOP stuff... :-)
Honestly, I think PHP's record of usage speaks far more volumes about
its quality and utility than any ribbing from "other" language users.
I'm reminded of how often we used to rib MS users of how their OS
wasn't a "real" OS because it couldn't do X, so they finally fixed it
to do X a couple years ago...
[Something or other about TCP/IP/SMTP/raw/root access, if you care to
refresh my memory...]
The end result, though, after they "fixed" it, was that we had a
zillion more security holes and viruses because now normal scripts
could punch through with this new feature.
Anyway, my point is that I also believe namespaces would be "good" for
those who need to distribute libraries and whatnot, possibly even more
important than OOP was in the first place -- As much of the OOP code
is little more than a namespace substitute in the first place.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Daniel T. Gorski wrote:
Escpecially due to the new OO features of PHP 5, namespaces are urgently
required for writers of independent libraries which should not clash.
I would claim exactly the opposite.
That's because you already get scoping on names, for free, when you use
objects. The method and field names. Of course, for static methods and
fields you'll need to reference the class name again ... so don't do
that :-)
There would typically be a one time 'hit' in your code for a long,
prefixed named used as a constructor, or possibly a static method called
on a factory. After that, if you're dealing with object instances, then
instead of function names (which would need to also use a longish
prefix, because they are scoped globally), you can use plain old short
method names.
--
Patrick_Mueller@us.ibm.com
IBM PHP Community Architect, IBM Research Triangle Park
While I could munge the class names in one or more packages as you
suggest then I'm in maintainability hell because when I need to update
one of the other packages (for security, features or bugfixes) you have
to do the name munging again.
C'mon, that ain't right. Next excuse?
--Tony
Patrick Mueller wrote:
Daniel T. Gorski wrote:
I would claim exactly the opposite.
That's because you already get scoping on names, for free, when you use
objects. The method and field names. Of course, for static methods and
fields you'll need to reference the class name again ... so don't do
that :-)There would typically be a one time 'hit' in your code for a long,
prefixed named used as a constructor, or possibly a static method called
on a factory. After that, if you're dealing with object instances, then
instead of function names (which would need to also use a longish
prefix, because they are scoped globally), you can use plain old short
method names.
While I could munge the class names in one or more packages as you
suggest then I'm in maintainability hell because when I need to
update one of the other packages (for security, features or
bugfixes) you have to do the name munging again.
What? I suppose if you always want to name your latest class foobar,
then yes, but then you have other problems... If you properly pick a
classname you almost never need to rename it let alone the methods
contained with the class. Plus namespaces are going to introduce
their own sets of problems where extension X adds namespace X, which
some lib already decided to use and we are back to where we are at
today.
Ilia Alshanetsky
Ilia Alshanetsky wrote:
If you properly pick a
classname you almost never need to rename it let alone the methods
contained with the class. Plus namespaces are going to introduce their
own sets of problems where extension X adds namespace X, which some lib
already decided to use and we are back to where we are at today.
In third party packages that choice isn't up to me.
And as for your extensions using the same namespace...I see that
argument as a bit better reasoning but would it not be easier to fix the
namespace declarations than having to fix ALL the uses of some class?
As a casual observer of this list and proponent of PHP I'd like to see
the namespace issue either get done or die. Many watching the namespace
issue with interest are growing tired of excuses as to why it shouldn't
be done.
Do it. Don't do it. Just choose and be on with it. PHP developers
will deal with the outcome fine. That isn't criticism directed at
anyone but dragging this out is only stirring emotions. I think putting
this behind us all - one way or another - is good for everybody.
--Tony
Ilia Alshanetsky
What? I suppose if you always want to name your latest class
foobar, then yes, but then you have other problems... If you
properly pick a classname you almost never need to rename it let
alone the methods contained with the class. Plus namespaces are
going to introduce their own sets of problems where extension X
adds namespace X, which some lib already decided to use and we are
back to where we are at today.
import('org.phpdb.propel.runtime'); or whatever. How could that
possibly collide. Come on, "people might use namespaces in a wrong
way" really is not an argument against them.
David
Tony Bibbs wrote:
While I could munge the class names in one or more packages as you
suggest then I'm in maintainability hell because when I need to update
one of the other packages (for security, features or bugfixes) you have
to do the name munging again.C'mon, that ain't right. Next excuse?
Sorry. I'm assuming here that you are giving your class names
'prefixed' names. Like Zend Framework is doing.
For what it's worth, >10 years ago we were in this same position with
Smalltalk; and specifically, IBM Smalltalk. Tradtional Smalltalk does
not have namespaces. And neither did ours - we were traditional :-)
So, we used product prefixes. We had a relatively hugemongous class
library, a fairly large, distributed team, and just a handful of
prefixes. It was 'ugly', to some extent, but it did work.
Later, we added namespaces. I never used 'em. Not sure if anyone did.
We added them because the masses roared for them. I don't think they
used 'em either. Because they were kinda horky. (Be careful what you
ask for, because you might just get it)
Point is, if you're doing OO in the usual fashion, the only time you
need to reference globally scoped names is when you reference the class
itself, which is when you invoke constructors, or call static methods.
Instance method invocation was used waaaaaay more often than those two.
--
Patrick_Mueller@us.ibm.com
IBM PHP Community Architect, IBM Research Triangle Park
Patrick Mueller wrote:
There would typically be a one time 'hit' in your code for a long,
prefixed named used as a constructor, or possibly a static method called
on a factory. After that, if you're dealing with object instances, then
instead of function names (which would need to also use a longish
prefix, because they are scoped globally), you can use plain old short
method names.
Remember the point Sebastian made earlier. Its also a hassle during
development of the library code itself, where you have to deal with
endlessly long class names.
regards,
Lukas
Remember the point Sebastian made earlier. Its also a hassle during
development of the library code itself, where you have to deal with
endlessly long class names.
You still have the same long names, you've just split them into two
namespaces + classname rather then just one class name.
Ilia Alshanetsky
Remember the point Sebastian made earlier. Its also a hassle during
development of the library code itself, where you have to deal with
endlessly long class names.You still have the same long names, you've just split them into two
namespaces + classname rather then just one class name.
This all also rather depends upon the eventual implementation.
I'm sure you're aware that in some languages it is possible to
'import' another namespace and re-name it to NOT conflict with
existing namespaces.
This also allows one to short the name of the namespace if it is
ridiculously long:
import('stupidly_long_brand_aware_name_space_foo.php', 'foo');
That feature may already be "off the table" for PHP in this
discussion, but it may explain this dichotomy of what different
posters are thinking namespaces will "fix" or "not fix"...
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Ilia Alshanetsky wrote:
If anything it'll make code complex and intertwined, introduce serious
scope issue most people have not had to consider up until now and so
on. It will without a doubt increase language complexity as well, which
generally translates to a loss in performance.
Am I right to assume that both scoping and performance issues only come
up if we were to implement an import() mechanism? If so, do we really
need import?
If not, then
namespace foo
{
class bar
{
}
}
would be "mangled" at compile-time into foo\bar and should not impose
any performance penalty or scoping issues.
Not having an import() mechanism, however, would mean that the user of
a namespaced package has to use "fully qualified" class names (like
foo\bar, for instance) while the developer of the namespaced package
can (and should) use the "relative" class name. We would still get two
benefits out of this:
-
The developer of a package does not need to worry that his class (or
constant, function) names clash with his package's users. -
The developer of a package can shorten the class names inside his
namespaced package significantly.PHPUnit_Framework_TestCase {}
would become
namespace PHPUnit {
namespace Framework {
class TestCase {}
}
}
Classes inside PHPUnit\Framework could refer to the class as just
TestCase, classes inside PHPUnit as Framework\TestCase, and classes
outside PHPUnit as PHPUnit\Framework\TestCase.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Ilia Alshanetsky wrote:
If anything it'll make code complex and intertwined, introduce
serious
scope issue most people have not had to consider up until now and so
on. It will without a doubt increase language complexity as well,
which
generally translates to a loss in performance.Am I right to assume that both scoping and performance issues only
come
up if we were to implement an import() mechanism? If so, do we really
need import?If not, then
namespace foo
{
class bar
{
}
}would be "mangled" at compile-time into foo\bar and should not impose
any performance penalty or scoping issues.
As your key size increases the slower the key hash generation process
becomes, if you look at the PHP's hash key generation code you'll see
that it works best for 8 or less chars, anything longer and the
performance starts to drop. Add to this case-sensitivity issues and
you have an additional draw on your speed.
Obviously, by doing things at compile time you reduce overhead, so it
is a good idea, but it will not eliminate the performance penalties,
it'll probable halve them however.
Ilia Alshanetsky
Ilia Alshanetsky wrote:
As your key size increases the slower the key hash generation process
becomes, if you look at the PHP's hash key generation code you'll see
that it works best for 8 or less chars, anything longer and the
performance starts to drop.
It's been a long time since I studied hashes: are there no hashing
algorithms that perform better with more than 8 characters?
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Hello Sebastian,
the best ones unfortunatley are GPL and thus not acceptable. I once
played with case insensitive hashes. They worked very much faster -
but they had more conflicts. If we were about intel processors my
experience is that string functions can be optimized at assembler level
very much. For instance i once ago increased string up/downcase by 32
times using a table based xlat approach that was reading the string in
chunks of 4 byte. Maybe itcould be interesting to see whether we could
come up with a version that takes 4 byte or 8 byte chunks depending on
the cpu. And eventually we have hash codes in 64 bit machines be 8 bytes
long as well.
best regards
marcus
Friday, November 10, 2006, 7:20:59 PM, you wrote:
Ilia Alshanetsky wrote:
As your key size increases the slower the key hash generation process
becomes, if you look at the PHP's hash key generation code you'll see
that it works best for 8 or less chars, anything longer and the
performance starts to drop.
It's been a long time since I studied hashes: are there no hashing
algorithms that perform better with more than 8 characters?
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Best regards,
Marcus
Too long of an email to read :) but just wanted to give a heads-up that we
haven't forgotten about this (it's on the PHP 6 list).
We'll try and come with a proposal in the coming weeks with a way to do it.
-----Original Message-----
From: Sean Coates [mailto:sean@caedmon.net]
Sent: Friday, November 10, 2006 8:51 AM
To: internals
Subject: [PHP-DEV] Namespaces in PHP 6 - ++$takeHello all,
A number of factors have come together to prompt me to
possibly commit mailing-list-suicide by re-opening the
namespace issue.Last week at Zendcon, a number of PHP developers/community
members chatted about namespaces in PHP 6. That chat was the
prime motivator for this email, but the recent (be they
misguided) complaints about symbol collisions in DateTime, as
well as blog entries such as Jeff Moore's on maintainability [1].None of us chatting seemed to be able to come up with a good
reason we don't yet have namespaces, other than frustration
(the last time we discussed this, the thread became VERY long
and drawn out), indecision (we couldn't seem to come to a
decision on a suitable operator), and complacency.The way I see it is that implementing namespaces is a
technical hurdle, and the reasons we haven't jumped it are
political, not technical.So, let's deal with these 3 problems:
Frustration: this thread will likely get long. Please avoid
long-winded explanation of why you don't like the looks of
"" or how ":::" is hard to type. If you have something
relevant to say, it's probably already been said [2][3].
Please review the archives.Indecision: We couldn't decide on "" or ":::". What this
comes down to is that "" is the only remaining operator that
can be typed in a single keystroke on us_en keyboards. The
other choice was ":::". I, for one, am OK with either
operator. I think someone with appropriate (social) karma
needs to simply commit to one or the other, and we'll make
do... we always do.Complacency: Most of the time, I'm happy to maintain the
status quo in PHP-land. However, the lack of namespaces is
causing more trouble than its absence is preventing. I think
most PHP users would agree that namespaces are a welcome
addition, and without them, PHP suffers. Let's take this in
small steps and implement optional userspace namespacing.
There's no need to dive head-first into this and make
dramatic moves like putting all core functions into a PHP
namespace. Baby steps, please.And, in conclusion (thanks for reading this far; I've
certainly exceeded the average non-code-paste post length, a
few times over), remember that the core devs discussed this
in Paris, last year [4]. They didn't come to a conclusion
(note the use of "if"), though.Let's settle this political issue, please, so we can get on
to solving the technical issues that will inevitably crop up.S
[1]
http://www.procata.com/blog/archives/2006/11/09/why-is-php-cod
e-considered-hard-to-maintain/
[2] http://beeblex.com/lists/index.php/php.internals/20586
[3] http://beeblex.com/lists/index.php/php.internals/17484
[4] http://php.net/~derick/meeting-notes.html#name-spaces--
To
unsubscribe, visit: http://www.php.net/unsub.php
Hello Internals.
I'm not sure how many of you know about Phalanger [1][2]. For those who
don't, it's a fairly complete PHP language compiler, compiling PHP5 sources
into MSIL bytecodes, which can then be executed on the .NET platform or
Mono. Since the .NET framework makes heavy use of namespaces, Phalanger had
to support it (from version 2.0). For those who already knew about Phalanger
and consider it obsolete after looking at version 1.x, I'd say take a look
at version 2.0b3, now it's accutually intresting.
For all the developers worldwide, I'd say it'd be nice if all implentations
used the same syntax. The Phalanger team went with the ::: syntax, possibly
'cause it seemed to get most votes last time the issue was up. I'm not
saying it should be a deciding factor, but taking it into consideration
wouldn't hurt, and should you decide against :::, I'm sure it would be
greatly appreciated if you at least did so before it gets widespread use.
Disclaimer:
I'm not part of the Phalanger team, and I have never had anything to do with
them. The above comments and thoughts are mine as a PHP developer, with an
additional interest in the possibilites of the .NET platform/framework.
(As a sidenote, Phalanger isn't the only other implentation currently
avaible, perhaps it's time to write down a standards document?)
[1] http://www.codeplex.com/Phalanger
[2] http://www.php-compiler.net/
--
"Sean Coates" sean@caedmon.net skrev i meddelandet
news:4554AE0D.4080600@caedmon.net...
Hello all,
A number of factors have come together to prompt me to possibly commit
mailing-list-suicide by re-opening the namespace issue.Last week at Zendcon, a number of PHP developers/community members
chatted about namespaces in PHP 6. That chat was the prime motivator for
this email, but the recent (be they misguided) complaints about symbol
collisions in DateTime, as well as blog entries such as Jeff Moore's on
maintainability [1].None of us chatting seemed to be able to come up with a good reason we
don't yet have namespaces, other than frustration (the last time we
discussed this, the thread became VERY long and drawn out), indecision
(we couldn't seem to come to a decision on a suitable operator), and
complacency.The way I see it is that implementing namespaces is a technical hurdle,
and the reasons we haven't jumped it are political, not technical.So, let's deal with these 3 problems:
Frustration: this thread will likely get long. Please avoid long-winded
explanation of why you don't like the looks of "" or how ":::" is hard
to type. If you have something relevant to say, it's probably already
been said [2][3]. Please review the archives.Indecision: We couldn't decide on "" or ":::". What this comes down to
is that "" is the only remaining operator that can be typed in a single
keystroke on us_en keyboards. The other choice was ":::". I, for one, am
OK with either operator. I think someone with appropriate (social) karma
needs to simply commit to one or the other, and we'll make do... we
always do.Complacency: Most of the time, I'm happy to maintain the status quo in
PHP-land. However, the lack of namespaces is causing more trouble than
its absence is preventing. I think most PHP users would agree that
namespaces are a welcome addition, and without them, PHP suffers. Let's
take this in small steps and implement optional userspace namespacing.
There's no need to dive head-first into this and make dramatic moves
like putting all core functions into a PHP namespace. Baby steps, please.And, in conclusion (thanks for reading this far; I've certainly exceeded
the average non-code-paste post length, a few times over), remember that
the core devs discussed this in Paris, last year [4]. They didn't come
to a conclusion (note the use of "if"), though.Let's settle this political issue, please, so we can get on to solving
the technical issues that will inevitably crop up.S
[1]
http://www.procata.com/blog/archives/2006/11/09/why-is-php-code-considered-hard-to-maintain/
[2] http://beeblex.com/lists/index.php/php.internals/20586
[3] http://beeblex.com/lists/index.php/php.internals/17484
[4] http://php.net/~derick/meeting-notes.html#name-spaces
Hello,
I haven't had time to work on my patch, but thinking about this some
more, I'm convinced namespaces should only contain classes. The only
problem that was present when permitting functions/constants to be
inside namespaces was the ambiguity in ternary expressions. By just
supporting classes inside namespaces, this issue would go away. Besides,
I'll dare say that most, if not all, the developers who want namespaces
will only group classes with it anyways,
Also, by only supporting classes, we can use ":" instead of the long
":::" separator and everyone would be happy.
Last I checked, the only things that were pending on my patch were some
scoping issues which I had to fix. These are listed below. Once these
are done, the patch can be formally proposed. If anyone wants to take a
look at the patch so far and/or work on the remaining issues below, let
me know and I'll either post the patch or email it.
Pending:
- The extends clause should resolve imported class names.
import class ns:DateBase;
namespace ns{ class Date extends DateBase{} }
-
To access a global symbol, use global:<class_name> syntax.
-
Type hints should also consider imported classes.
-
When an import is done (with alias or not), and a global class with
that same name exists, what is the desired behavior? Error? Global takes
precedence?
Regards,
Jessie Hernandez
Sean Coates wrote:
Hello all,
A number of factors have come together to prompt me to possibly commit
mailing-list-suicide by re-opening the namespace issue.Last week at Zendcon, a number of PHP developers/community members
chatted about namespaces in PHP 6. That chat was the prime motivator for
this email, but the recent (be they misguided) complaints about symbol
collisions in DateTime, as well as blog entries such as Jeff Moore's on
maintainability [1].None of us chatting seemed to be able to come up with a good reason we
don't yet have namespaces, other than frustration (the last time we
discussed this, the thread became VERY long and drawn out), indecision
(we couldn't seem to come to a decision on a suitable operator), and
complacency.The way I see it is that implementing namespaces is a technical hurdle,
and the reasons we haven't jumped it are political, not technical.So, let's deal with these 3 problems:
Frustration: this thread will likely get long. Please avoid long-winded
explanation of why you don't like the looks of "" or how ":::" is hard
to type. If you have something relevant to say, it's probably already
been said [2][3]. Please review the archives.Indecision: We couldn't decide on "" or ":::". What this comes down to
is that "" is the only remaining operator that can be typed in a single
keystroke on us_en keyboards. The other choice was ":::". I, for one, am
OK with either operator. I think someone with appropriate (social) karma
needs to simply commit to one or the other, and we'll make do... we
always do.Complacency: Most of the time, I'm happy to maintain the status quo in
PHP-land. However, the lack of namespaces is causing more trouble than
its absence is preventing. I think most PHP users would agree that
namespaces are a welcome addition, and without them, PHP suffers. Let's
take this in small steps and implement optional userspace namespacing.
There's no need to dive head-first into this and make dramatic moves
like putting all core functions into a PHP namespace. Baby steps, please.And, in conclusion (thanks for reading this far; I've certainly exceeded
the average non-code-paste post length, a few times over), remember that
the core devs discussed this in Paris, last year [4]. They didn't come
to a conclusion (note the use of "if"), though.Let's settle this political issue, please, so we can get on to solving
the technical issues that will inevitably crop up.S
[1]
http://www.procata.com/blog/archives/2006/11/09/why-is-php-code-considered-hard-to-maintain/
[2] http://beeblex.com/lists/index.php/php.internals/20586
[3] http://beeblex.com/lists/index.php/php.internals/17484
[4] http://php.net/~derick/meeting-notes.html#name-spaces
Hello Jessie,
sorry to say this but look at the following, keeping in mind that the
whitespace is optional.
$x = $foo ? class:const : $var // 1, 0
$x = $foo ? class:const : const; // 1, 0
$x = $foo ? class:const : class:const; // 1, 1
$x = $foo ? class:const : namespace:class:const; // 1, 2
$x = $foo ? namespace:class:const : $var; // 2, 0
$x = $foo ? namespace:class:const : const; // 2, 0
$x = $foo ? namespace:class:const : class:const; // 2, 1
$x = $foo ? namespace:class:const : namespace:class:const; // 2, 2
Feel free to continue that list, it has conflicts whatever you do.
Saturday, November 11, 2006, 5:13:22 AM, you wrote:
Hello,
I haven't had time to work on my patch, but thinking about this some
more, I'm convinced namespaces should only contain classes. The only
problem that was present when permitting functions/constants to be
inside namespaces was the ambiguity in ternary expressions. By just
supporting classes inside namespaces, this issue would go away. Besides,
I'll dare say that most, if not all, the developers who want namespaces
will only group classes with it anyways,
Also, by only supporting classes, we can use ":" instead of the long
":::" separator and everyone would be happy.
Last I checked, the only things that were pending on my patch were some
scoping issues which I had to fix. These are listed below. Once these
are done, the patch can be formally proposed. If anyone wants to take a
look at the patch so far and/or work on the remaining issues below, let
me know and I'll either post the patch or email it.
Pending:
- The extends clause should resolve imported class names.
import class ns:DateBase;
namespace ns{ class Date extends DateBase{} }
- To access a global symbol, use global:<class_name> syntax.
I would prefer ':::'<class_name> or ''<class_name> but that doesn't really
matter as we have 'global' as a keyword already.
- Type hints should also consider imported classes.
- When an import is done (with alias or not), and a global class with
that same name exists, what is the desired behavior? Error? Global takes
precedence?
Maybe this new discussion gave one hint. Aliases could be solved with a
flag. Just copy the classwith a new name into the classlist again and flagit
as copy. Maybe the original class gets a list of the copies of the copies a
pointer to the original but that would be an implementation detail. As soon
as that is done importdoes nothingelse then copying classes on a single
class table. That said namespaces would, if after all, simply contain other
copies to the original classes. In the extremecase we can start with
namespaces only being a 'stupid' list. Reflection could then travers all
classes to see in which namespaces it was registered.
This btw would also fix 3) as the namespace seperator would be a normal
sign in class lookup, it would simply be disallowed in definitions of
class/interface/namespaces.
Best regards,
Marcus
Hi Marcus,
As I said, I wanted to only enable classes inside namespaces, and NOT
allow functions or constants. class::const would stay the same, so there
are no conflicts.
Marcus Boerger wrote:
Hello Jessie,
sorry to say this but look at the following, keeping in mind that the
whitespace is optional.$x = $foo ? class:const : $var // 1, 0
$x = $foo ? class:const : const; // 1, 0
$x = $foo ? class:const : class:const; // 1, 1
$x = $foo ? class:const : namespace:class:const; // 1, 2
$x = $foo ? namespace:class:const : $var; // 2, 0
$x = $foo ? namespace:class:const : const; // 2, 0
$x = $foo ? namespace:class:const : class:const; // 2, 1
$x = $foo ? namespace:class:const : namespace:class:const; // 2, 2Feel free to continue that list, it has conflicts whatever you do.
Saturday, November 11, 2006, 5:13:22 AM, you wrote:
Hello,
I haven't had time to work on my patch, but thinking about this some
more, I'm convinced namespaces should only contain classes. The only
problem that was present when permitting functions/constants to be
inside namespaces was the ambiguity in ternary expressions. By just
supporting classes inside namespaces, this issue would go away. Besides,
I'll dare say that most, if not all, the developers who want namespaces
will only group classes with it anyways,Also, by only supporting classes, we can use ":" instead of the long
":::" separator and everyone would be happy.Last I checked, the only things that were pending on my patch were some
scoping issues which I had to fix. These are listed below. Once these
are done, the patch can be formally proposed. If anyone wants to take a
look at the patch so far and/or work on the remaining issues below, let
me know and I'll either post the patch or email it.Pending:
- The extends clause should resolve imported class names.
import class ns:DateBase;
namespace ns{ class Date extends DateBase{} }
- To access a global symbol, use global:<class_name> syntax.
I would prefer ':::'<class_name> or ''<class_name> but that doesn't really
matter as we have 'global' as a keyword already.
- Type hints should also consider imported classes.
- When an import is done (with alias or not), and a global class with
that same name exists, what is the desired behavior? Error? Global takes
precedence?Maybe this new discussion gave one hint. Aliases could be solved with a
flag. Just copy the classwith a new name into the classlist again and flagit
as copy. Maybe the original class gets a list of the copies of the copies a
pointer to the original but that would be an implementation detail. As soon
as that is done importdoes nothingelse then copying classes on a single
class table. That said namespaces would, if after all, simply contain other
copies to the original classes. In the extremecase we can start with
namespaces only being a 'stupid' list. Reflection could then travers all
classes to see in which namespaces it was registered.This btw would also fix 3) as the namespace seperator would be a normal
sign in class lookup, it would simply be disallowed in definitions of
class/interface/namespaces.Best regards,
Marcus
Hi!
If the namespace-approach only covers classes it is implemented
half-heartedly, IMO. I see a lot of "classes" that are just really
collections of static functions, that's what namespaces should cover,
too. And disallowing constants only so that : works is a bad tradeoff...
Regards,
Stefan
What does everyone else think? Are functions/constants inside namespaces
really that critical?
Anyways, I just thought of a possible solution to the namespace
separator issue, and if it's doable, then the double colon (::) can even
be used and no conflicts would occur. It seems the biggest problem with
handling namespaces is determining if a symbol is a class or namespace
at compile-time. I am no expert in flex/bison, but I was thinking that a
state can be used, such as LOOKING_FOR_CLASS_OR_NAMESPACE, which will
return either a T_CLASS_NAME or T_NAMESPACE_NAME token depending on
whether the symbol is known to be a class or namespace. The user will
add either a "using" or "import" statement before the use of the symbol,
and this will allow the parser to know what that symbol is in the
compilation phase. As an example:
// BEGIN CODE
using namespace PEAR::File;
$items = File::Find::glob( '!.*.php$!', $dir, 'perl' );
// END CODE
The first statement will add an entry into a hashtable (used during
compilation) indicating that "PEAR", "PEAR::File", and "File" are
namespaces ("File" will be imported in the current file only). When
"File::Find::glob" is parsed, the compiler already knows that "File" is
a namespace, so "Find" must be a class inside that namespace, and "glob"
must be a static method. With this, functions and constants can easily
be added inside namespaces, as the "using" or "import" statement will
indicate to the parser which portion of the qualified name is a namespace.
Is this feasible in flex/bison? Let me know if anything needs clarification.
Regards,
Jessie Hernandez
Stefan Walk wrote:
Hi!
If the namespace-approach only covers classes it is implemented
half-heartedly, IMO. I see a lot of "classes" that are just really
collections of static functions, that's what namespaces should cover,
too. And disallowing constants only so that : works is a bad tradeoff...Regards,
Stefan
Hello Jessie,
Tuesday, November 14, 2006, 5:00:42 AM, you wrote:
What does everyone else think? Are functions/constants inside namespaces
really that critical?
Anyways, I just thought of a possible solution to the namespace
separator issue, and if it's doable, then the double colon (::) can even
be used and no conflicts would occur. It seems the biggest problem with
handling namespaces is determining if a symbol is a class or namespace
at compile-time. I am no expert in flex/bison, but I was thinking that a
state can be used, such as LOOKING_FOR_CLASS_OR_NAMESPACE, which will
return either a T_CLASS_NAME or T_NAMESPACE_NAME token depending on
whether the symbol is known to be a class or namespace. The user will
add either a "using" or "import" statement before the use of the symbol,
and this will allow the parser to know what that symbol is in the
compilation phase. As an example:
// BEGIN CODE
using namespace PEAR::File;
$items = File::Find::glob( '!.*.php$!', $dir, 'perl' );
// END CODE
The first statement will add an entry into a hashtable (used during
compilation) indicating that "PEAR", "PEAR::File", and "File" are
namespaces ("File" will be imported in the current file only). When
"File::Find::glob" is parsed, the compiler already knows that "File" is
a namespace, so "Find" must be a class inside that namespace, and "glob"
must be a static method. With this, functions and constants can easily
be added inside namespaces, as the "using" or "import" statement will
indicate to the parser which portion of the qualified name is a namespace.
Is this feasible in flex/bison? Let me know if anything needs clarification.
Short: no
Long: Please stop confusion here. We will get namespace innwith either ":::"
or "" depending on who is going to implement it and what otherissues that
one will encounter. Later we may decide based on that implementation whether
it might be possible to use a different seperator. Btw, ifI wereto implement
namespacesupport today i would go with "" as that is easier to translate to
a directory/file name in an __autoload function. While yesturday people
nearly convinced me (during the last conferences) that ":::" is closer to
the class/member seperator "::".
best regards
marcus
The only issue with using \ is the fact that this is the escape
character. If you are using PHP to create classes (collapsing complex
classes into simpler ones, implementing a fake AOP), you have to
remember to escape the escape. It just seems odd to re-use a symbol
like this. A new symbol is better. IIHMY, I would use # and remove #
from comments. # looks like a grid which can be thought of as a
compartmentalisation process; i.e. grouping things together in their
own little space - a perfect concept to explain namespaces. We already
have singleline and block comments with // and /* ... */. Not really
sure of the need of #. Of course, this would be an evern bigger BC.
Even my own code uses #.
The triple colon (:::) is OK, but what happens during a mistype. Is
there a possibility that :: and ::: COULD be used interchangably (an
extreme example), producing working code?
Hello Jessie,
Tuesday, November 14, 2006, 5:00:42 AM, you wrote:
What does everyone else think? Are functions/constants inside namespaces
really that critical?Anyways, I just thought of a possible solution to the namespace
separator issue, and if it's doable, then the double colon (::) can even
be used and no conflicts would occur. It seems the biggest problem with
handling namespaces is determining if a symbol is a class or namespace
at compile-time. I am no expert in flex/bison, but I was thinking that a
state can be used, such as LOOKING_FOR_CLASS_OR_NAMESPACE, which will
return either a T_CLASS_NAME or T_NAMESPACE_NAME token depending on
whether the symbol is known to be a class or namespace. The user will
add either a "using" or "import" statement before the use of the symbol,
and this will allow the parser to know what that symbol is in the
compilation phase. As an example:// BEGIN CODE
using namespace PEAR::File;
$items = File::Find::glob( '!.*.php$!', $dir, 'perl' );
// END CODEThe first statement will add an entry into a hashtable (used during
compilation) indicating that "PEAR", "PEAR::File", and "File" are
namespaces ("File" will be imported in the current file only). When
"File::Find::glob" is parsed, the compiler already knows that "File" is
a namespace, so "Find" must be a class inside that namespace, and "glob"
must be a static method. With this, functions and constants can easily
be added inside namespaces, as the "using" or "import" statement will
indicate to the parser which portion of the qualified name is a namespace.Is this feasible in flex/bison? Let me know if anything needs clarification.
Short: no
Long: Please stop confusion here. We will get namespace innwith either ":::"
or "" depending on who is going to implement it and what otherissues that
one will encounter. Later we may decide based on that implementation whether
it might be possible to use a different seperator. Btw, ifI wereto implement
namespacesupport today i would go with "" as that is easier to translate to
a directory/file name in an __autoload function. While yesturday people
nearly convinced me (during the last conferences) that ":::" is closer to
the class/member seperator "::".best regards
marcus--
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Hello Richard,
The "#" is needed for CLI mode - thus we won't remove it. In fact we
will not do anything that would cause BC problems. Also there is no
escaping issue with "". If there is than it is outside of PHP. In
other words:
- "" is the only single character reachable from 'western' keyboards
- $foo = "{mynamespace\myclass::myconst}"; // will be possible without
escaping
Please people read the archives before posting here, we have discussed
all this long enough.
Tuesday, November 14, 2006, 9:36:10 AM, you wrote:
The only issue with using \ is the fact that this is the escape
character. If you are using PHP to create classes (collapsing complex
classes into simpler ones, implementing a fake AOP), you have to
remember to escape the escape. It just seems odd to re-use a symbol
like this. A new symbol is better. IIHMY, I would use # and remove #
from comments. # looks like a grid which can be thought of as a
compartmentalisation process; i.e. grouping things together in their
own little space - a perfect concept to explain namespaces. We already
have singleline and block comments with // and /* ... */. Not really
sure of the need of #. Of course, this would be an evern bigger BC.
Even my own code uses #.
The triple colon (:::) is OK, but what happens during a mistype. Is
there a possibility that :: and ::: COULD be used interchangably (an
extreme example), producing working code?
Hello Jessie,
Tuesday, November 14, 2006, 5:00:42 AM, you wrote:
What does everyone else think? Are functions/constants inside namespaces
really that critical?Anyways, I just thought of a possible solution to the namespace
separator issue, and if it's doable, then the double colon (::) can even
be used and no conflicts would occur. It seems the biggest problem with
handling namespaces is determining if a symbol is a class or namespace
at compile-time. I am no expert in flex/bison, but I was thinking that a
state can be used, such as LOOKING_FOR_CLASS_OR_NAMESPACE, which will
return either a T_CLASS_NAME or T_NAMESPACE_NAME token depending on
whether the symbol is known to be a class or namespace. The user will
add either a "using" or "import" statement before the use of the symbol,
and this will allow the parser to know what that symbol is in the
compilation phase. As an example:// BEGIN CODE
using namespace PEAR::File;
$items = File::Find::glob( '!.*.php$!', $dir, 'perl' );
// END CODEThe first statement will add an entry into a hashtable (used during
compilation) indicating that "PEAR", "PEAR::File", and "File" are
namespaces ("File" will be imported in the current file only). When
"File::Find::glob" is parsed, the compiler already knows that "File" is
a namespace, so "Find" must be a class inside that namespace, and "glob"
must be a static method. With this, functions and constants can easily
be added inside namespaces, as the "using" or "import" statement will
indicate to the parser which portion of the qualified name is a namespace.Is this feasible in flex/bison? Let me know if anything needs clarification.
Short: no
Long: Please stop confusion here. We will get namespace innwith either ":::"
or "" depending on who is going to implement it and what otherissues that
one will encounter. Later we may decide based on that implementation whether
it might be possible to use a different seperator. Btw, ifI wereto implement
namespacesupport today i would go with "" as that is easier to translate to
a directory/file name in an __autoload function. While yesturday people
nearly convinced me (during the last conferences) that ":::" is closer to
the class/member seperator "::".best regards
marcus--
Best regards,
Marcus
Marcus Boerger wrote:
Hello Richard,
The "#" is needed for CLI mode - thus we won't remove it. In fact we
will not do anything that would cause BC problems. Also there is no
escaping issue with "". If there is than it is outside of PHP. In
other words:
- "" is the only single character reachable from 'western' keyboards
- $foo = "{mynamespace\myclass::myconst}"; // will be possible without
escapingPlease people read the archives before posting here, we have discussed
all this long enough.
Jessie, Sean,
would you guys be interested in writing up an overview of the namespace
decisions on my todo wiki?
regards,
Lukas
Would $foo = "{mynamespace\tables_class::myconst}";
\t in "" is a tab. \m in "" is nothing but \m
Thats the sort of thing I'm worried about.
Hello Richard,
The "#" is needed for CLI mode - thus we won't remove it. In fact we
will not do anything that would cause BC problems. Also there is no
escaping issue with "". If there is than it is outside of PHP. In
other words:
- "" is the only single character reachable from 'western' keyboards
- $foo = "{mynamespace\myclass::myconst}"; // will be possible without
escapingPlease people read the archives before posting here, we have discussed
all this long enough.Tuesday, November 14, 2006, 9:36:10 AM, you wrote:
The only issue with using \ is the fact that this is the escape
character. If you are using PHP to create classes (collapsing complex
classes into simpler ones, implementing a fake AOP), you have to
remember to escape the escape. It just seems odd to re-use a symbol
like this. A new symbol is better. IIHMY, I would use # and remove #
from comments. # looks like a grid which can be thought of as a
compartmentalisation process; i.e. grouping things together in their
own little space - a perfect concept to explain namespaces. We already
have singleline and block comments with // and /* ... */. Not really
sure of the need of #. Of course, this would be an evern bigger BC.
Even my own code uses #.The triple colon (:::) is OK, but what happens during a mistype. Is
there a possibility that :: and ::: COULD be used interchangably (an
extreme example), producing working code?Hello Jessie,
Tuesday, November 14, 2006, 5:00:42 AM, you wrote:
What does everyone else think? Are functions/constants inside namespaces
really that critical?Anyways, I just thought of a possible solution to the namespace
separator issue, and if it's doable, then the double colon (::) can even
be used and no conflicts would occur. It seems the biggest problem with
handling namespaces is determining if a symbol is a class or namespace
at compile-time. I am no expert in flex/bison, but I was thinking that a
state can be used, such as LOOKING_FOR_CLASS_OR_NAMESPACE, which will
return either a T_CLASS_NAME or T_NAMESPACE_NAME token depending on
whether the symbol is known to be a class or namespace. The user will
add either a "using" or "import" statement before the use of the symbol,
and this will allow the parser to know what that symbol is in the
compilation phase. As an example:// BEGIN CODE
using namespace PEAR::File;
$items = File::Find::glob( '!.*.php$!', $dir, 'perl' );
// END CODEThe first statement will add an entry into a hashtable (used during
compilation) indicating that "PEAR", "PEAR::File", and "File" are
namespaces ("File" will be imported in the current file only). When
"File::Find::glob" is parsed, the compiler already knows that "File" is
a namespace, so "Find" must be a class inside that namespace, and "glob"
must be a static method. With this, functions and constants can easily
be added inside namespaces, as the "using" or "import" statement will
indicate to the parser which portion of the qualified name is a namespace.Is this feasible in flex/bison? Let me know if anything needs clarification.
Short: no
Long: Please stop confusion here. We will get namespace innwith either ":::"
or "" depending on who is going to implement it and what otherissues that
one will encounter. Later we may decide based on that implementation whether
it might be possible to use a different seperator. Btw, ifI wereto implement
namespacesupport today i would go with "" as that is easier to translate to
a directory/file name in an __autoload function. While yesturday people
nearly convinced me (during the last conferences) that ":::" is closer to
the class/member seperator "::".best regards
marcus--
Best regards,
Marcus
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
Hello Richard,
as though what you say is true the rules are different inside {} inside "".
best regards
marcus
Wednesday, November 15, 2006, 9:39:48 AM, you wrote:
Would $foo = "{mynamespace\tables_class::myconst}";
\t in "" is a tab. \m in "" is nothing but \m
Thats the sort of thing I'm worried about.
Hello Richard,
The "#" is needed for CLI mode - thus we won't remove it. In fact we
will not do anything that would cause BC problems. Also there is no
escaping issue with "". If there is than it is outside of PHP. In
other words:
- "" is the only single character reachable from 'western' keyboards
- $foo = "{mynamespace\myclass::myconst}"; // will be possible without
escapingPlease people read the archives before posting here, we have discussed
all this long enough.Tuesday, November 14, 2006, 9:36:10 AM, you wrote:
The only issue with using \ is the fact that this is the escape
character. If you are using PHP to create classes (collapsing complex
classes into simpler ones, implementing a fake AOP), you have to
remember to escape the escape. It just seems odd to re-use a symbol
like this. A new symbol is better. IIHMY, I would use # and remove #
from comments. # looks like a grid which can be thought of as a
compartmentalisation process; i.e. grouping things together in their
own little space - a perfect concept to explain namespaces. We already
have singleline and block comments with // and /* ... */. Not really
sure of the need of #. Of course, this would be an evern bigger BC.
Even my own code uses #.The triple colon (:::) is OK, but what happens during a mistype. Is
there a possibility that :: and ::: COULD be used interchangably (an
extreme example), producing working code?Hello Jessie,
Tuesday, November 14, 2006, 5:00:42 AM, you wrote:
What does everyone else think? Are functions/constants inside namespaces
really that critical?Anyways, I just thought of a possible solution to the namespace
separator issue, and if it's doable, then the double colon (::) can even
be used and no conflicts would occur. It seems the biggest problem with
handling namespaces is determining if a symbol is a class or namespace
at compile-time. I am no expert in flex/bison, but I was thinking that a
state can be used, such as LOOKING_FOR_CLASS_OR_NAMESPACE, which will
return either a T_CLASS_NAME or T_NAMESPACE_NAME token depending on
whether the symbol is known to be a class or namespace. The user will
add either a "using" or "import" statement before the use of the symbol,
and this will allow the parser to know what that symbol is in the
compilation phase. As an example:// BEGIN CODE
using namespace PEAR::File;
$items = File::Find::glob( '!.*.php$!', $dir, 'perl' );
// END CODEThe first statement will add an entry into a hashtable (used during
compilation) indicating that "PEAR", "PEAR::File", and "File" are
namespaces ("File" will be imported in the current file only). When
"File::Find::glob" is parsed, the compiler already knows that "File" is
a namespace, so "Find" must be a class inside that namespace, and "glob"
must be a static method. With this, functions and constants can easily
be added inside namespaces, as the "using" or "import" statement will
indicate to the parser which portion of the qualified name is a namespace.Is this feasible in flex/bison? Let me know if anything needs clarification.
Short: no
Long: Please stop confusion here. We will get namespace innwith either ":::"
or "" depending on who is going to implement it and what otherissues that
one will encounter. Later we may decide based on that implementation whether
it might be possible to use a different seperator. Btw, ifI wereto implement
namespacesupport today i would go with "" as that is easier to translate to
a directory/file name in an __autoload function. While yesturday people
nearly convinced me (during the last conferences) that ":::" is closer to
the class/member seperator "::".best regards
marcus--
Best regards,
Marcus
Best regards,
Marcus
Hello Jessie,
we already have consts in our classes, if you look close then you will see
that the table does not conatain 'namespace:const' but only 'namespace:class'
and still there are conflicts already.
best regards
marcus
Sunday, November 12, 2006, 1:48:22 AM, you wrote:
Hi Marcus,
As I said, I wanted to only enable classes inside namespaces, and NOT
allow functions or constants. class::const would stay the same, so there
are no conflicts.
Marcus Boerger wrote:
Hello Jessie,
sorry to say this but look at the following, keeping in mind that the
whitespace is optional.$x = $foo ? class:const : $var // 1, 0
$x = $foo ? class:const : const; // 1, 0
$x = $foo ? class:const : class:const; // 1, 1
$x = $foo ? class:const : namespace:class:const; // 1, 2
$x = $foo ? namespace:class:const : $var; // 2, 0
$x = $foo ? namespace:class:const : const; // 2, 0
$x = $foo ? namespace:class:const : class:const; // 2, 1
$x = $foo ? namespace:class:const : namespace:class:const; // 2, 2Feel free to continue that list, it has conflicts whatever you do.
Saturday, November 11, 2006, 5:13:22 AM, you wrote:
Hello,
I haven't had time to work on my patch, but thinking about this some
more, I'm convinced namespaces should only contain classes. The only
problem that was present when permitting functions/constants to be
inside namespaces was the ambiguity in ternary expressions. By just
supporting classes inside namespaces, this issue would go away. Besides,
I'll dare say that most, if not all, the developers who want namespaces
will only group classes with it anyways,Also, by only supporting classes, we can use ":" instead of the long
":::" separator and everyone would be happy.Last I checked, the only things that were pending on my patch were some
scoping issues which I had to fix. These are listed below. Once these
are done, the patch can be formally proposed. If anyone wants to take a
look at the patch so far and/or work on the remaining issues below, let
me know and I'll either post the patch or email it.Pending:
- The extends clause should resolve imported class names.
import class ns:DateBase;
namespace ns{ class Date extends DateBase{} }
- To access a global symbol, use global:<class_name> syntax.
I would prefer ':::'<class_name> or ''<class_name> but that doesn't really
matter as we have 'global' as a keyword already.
- Type hints should also consider imported classes.
- When an import is done (with alias or not), and a global class with
that same name exists, what is the desired behavior? Error? Global takes
precedence?Maybe this new discussion gave one hint. Aliases could be solved with a
flag. Just copy the classwith a new name into the classlist again and flagit
as copy. Maybe the original class gets a list of the copies of the copies a
pointer to the original but that would be an implementation detail. As soon
as that is done importdoes nothingelse then copying classes on a single
class table. That said namespaces would, if after all, simply contain other
copies to the original classes. In the extremecase we can start with
namespaces only being a 'stupid' list. Reflection could then travers all
classes to see in which namespaces it was registered.This btw would also fix 3) as the namespace seperator would be a normal
sign in class lookup, it would simply be disallowed in definitions of
class/interface/namespaces.Best regards,
Marcus
Best regards,
Marcus
Hi Marcus,
Can you please clarify where the conflicts will occur if only classes
are allowed in namespaces?
Best regards,
Jessie Hernandez
Marcus Boerger wrote:
Hello Jessie,
we already have consts in our classes, if you look close then you will see
that the table does not conatain 'namespace:const' but only 'namespace:class'
and still there are conflicts already.best regards
marcusSunday, November 12, 2006, 1:48:22 AM, you wrote:
Hi Marcus,
As I said, I wanted to only enable classes inside namespaces, and NOT
allow functions or constants. class::const would stay the same, so there
are no conflicts.
Marcus Boerger wrote:
Hello Jessie,
[snip]
Maybe this new discussion gave one hint. Aliases could be solved with a
flag. Just copy the classwith a new name into the classlist again and flagit
as copy. Maybe the original class gets a list of the copies of the copies a
pointer to the original but that would be an implementation detail. As soon
as that is done importdoes nothingelse then copying classes on a single
class table. That said namespaces would, if after all, simply contain other
copies to the original classes. In the extremecase we can start with
namespaces only being a 'stupid' list. Reflection could then travers all
classes to see in which namespaces it was registered.This btw would also fix 3) as the namespace seperator would be a normal
sign in class lookup, it would simply be disallowed in definitions of
class/interface/namespaces.
Did not notice these further comments until now. Anyways, I originally
implemented imports in this way (making copies in class_table and
updating the reference count), but then I used another approach because
then imports would be request-wide, and I wanted them to be
file-specific only (yeah, I know the PHP6 meeting notes said they should
be request-wide, but I see this causing many problems to the point where
they cannot be used in order to guarantee safe code).
Also, yes, ':' are not be allowed in either class or interface
definitions, but they are included in the full name in class_table
(e.g. "namespace_name:class_name"). This is how it is currently in my patch.
Regards,
Jessie Hernandez
Sean,
I think there are fair chances we'll introduce a very simplistic
namespaces capability in PHP 6. It's pretty clear it will not have
the notion of imports, and will be very much focused on classes (as
opposed to functions and variables). In fact, I think you can very
much imagine them as being a new way of writing a class name - just
imagine you could specify a single colon (or whatever) in your class name.
Anything beyond that is going to result in a significant slowdown of
the execution engine and open a can of warms regarding scoping and
symbol resolution. Just to clarify what Rasmus said (which is indeed
what was agreed for PHP 6) - we will add namespaces to PHP 6 if we
can find a good way of defining their semantics in the PHP spirit as
well as an acceptable way to implement it. Those two reasons very
much limit what we can or cannot do with namespaces in PHP,
especially the first one.
Zeev
At 18:51 10/11/2006, Sean Coates wrote:
Hello all,
A number of factors have come together to prompt me to possibly commit
mailing-list-suicide by re-opening the namespace issue.Last week at Zendcon, a number of PHP developers/community members
chatted about namespaces in PHP 6. That chat was the prime motivator for
this email, but the recent (be they misguided) complaints about symbol
collisions in DateTime, as well as blog entries such as Jeff Moore's on
maintainability [1].None of us chatting seemed to be able to come up with a good reason we
don't yet have namespaces, other than frustration (the last time we
discussed this, the thread became VERY long and drawn out), indecision
(we couldn't seem to come to a decision on a suitable operator), and
complacency.The way I see it is that implementing namespaces is a technical hurdle,
and the reasons we haven't jumped it are political, not technical.So, let's deal with these 3 problems:
Frustration: this thread will likely get long. Please avoid long-winded
explanation of why you don't like the looks of "" or how ":::" is hard
to type. If you have something relevant to say, it's probably already
been said [2][3]. Please review the archives.Indecision: We couldn't decide on "" or ":::". What this comes down to
is that "" is the only remaining operator that can be typed in a single
keystroke on us_en keyboards. The other choice was ":::". I, for one, am
OK with either operator. I think someone with appropriate (social) karma
needs to simply commit to one or the other, and we'll make do... we
always do.Complacency: Most of the time, I'm happy to maintain the status quo in
PHP-land. However, the lack of namespaces is causing more trouble than
its absence is preventing. I think most PHP users would agree that
namespaces are a welcome addition, and without them, PHP suffers. Let's
take this in small steps and implement optional userspace namespacing.
There's no need to dive head-first into this and make dramatic moves
like putting all core functions into a PHP namespace. Baby steps, please.And, in conclusion (thanks for reading this far; I've certainly exceeded
the average non-code-paste post length, a few times over), remember that
the core devs discussed this in Paris, last year [4]. They didn't come
to a conclusion (note the use of "if"), though.Let's settle this political issue, please, so we can get on to solving
the technical issues that will inevitably crop up.S
[1]
http://www.procata.com/blog/archives/2006/11/09/why-is-php-code-considered-hard-to-maintain/
[2] http://beeblex.com/lists/index.php/php.internals/20586
[3] http://beeblex.com/lists/index.php/php.internals/17484
[4] http://php.net/~derick/meeting-notes.html#name-spaces
+1
Given the usage of \ for string escaping, I'd have to vote for :::, I
guess...
But it wouldn't kill me if \ won the vote either.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?