This is what I've be fearing. First slated for 5.0. Then 5.3. Now 6.0. It appears there's consensus to rip it out which, in my prior post, I was all for if people felt it meant getting it right. Apparently that is the case. I guess my main question is what keeps this from being pushed yet again once 6.0 drops? From the community standpoint we keep hearing "its coming, its coming" but here we are still waiting. Again, I'm fine with the decision but I think others share similar concerns and will want to hear a commitment (dare I say promise) to adding namespaces to 6.0.
--Tony
----- Original Message ----
From: Stefan Walk et@php.net
To: internals@lists.php.net
Sent: Tuesday, October 14, 2008 7:46:58 AM
Subject: Re: [PHP-DEV] namespaces and alpha3
On Tuesday 14 October 2008 14:10:50 Steph Fox wrote:
I'm +1 on ripping out and leaving til 6.0. I don't think there is enough
time between now and the 5.3.0 code freeze to make major changes to the
language syntax.
Major changes like ripping the feature that most people are looking forward to
in 5.3 out?
Making -> do double duty and adding
E_STRICTmessages to
currently legal code really doesn't look like a good option to me, much
less during a point release and even less during the final moments of a
release cycle.
That E_STRICT was proposed for 6, not for 5.3, and is not a requirement - and
about "double duty", it's not really unintuitive to reference to "members" of
classes the same way you reference to "members" of instances.
'An announcement has been done on php.net' simply isn't a good enough
reason to screw up the language; we can write new announcements and even
explanations. And we already have most of a working implementation in
6.0, so it's not like ripping it out of 5.3 means starting over from
scratch.
I would love to see the public reaction to those "new announcements and
explanations", so in a way it's a win-win situation for me.
Regards,
Stefan
Tony Bibbs wrote:
This is what I've be fearing. First slated for 5.0. Then 5.3. Now 6.0. It appears there's consensus to rip it out which, in my prior post, I was all for if people felt it meant getting it right. Apparently that is the case. I guess my main question is what keeps this from being pushed yet again once 6.0 drops? From the community standpoint we keep hearing "its coming, its coming" but here we are still waiting. Again, I'm fine with the decision but I think others share similar concerns and will want to hear a commitment (dare I say promise) to adding namespaces to 6.0.
--Tony
----- Original Message ----
From: Stefan Walk et@php.net
To: internals@lists.php.net
Sent: Tuesday, October 14, 2008 7:46:58 AM
Subject: Re: [PHP-DEV] namespaces and alpha3On Tuesday 14 October 2008 14:10:50 Steph Fox wrote:
I'm +1 on ripping out and leaving til 6.0. I don't think there is enough
time between now and the 5.3.0 code freeze to make major changes to the
language syntax.Major changes like ripping the feature that most people are looking forward to
in 5.3 out?
I'd really like to see namespace in 5.3. After reading most of the
threads I'm still not real sure what the real problem is with the
current implementation. It's down to stuff with constants and functions.
IMO namespaces are very much an OO thing, meaning constants and
functions should be in classes anyway. There's only a problem if you
want there to be a problem. Foo::Bar::baz() is in class Bar in namespace
Foo. Foo::Bar::BAZ is a constant in class Bar in namespace Foo.
Ron
Hi!
This is what I've be fearing. First slated for 5.0. Then 5.3. Now
6.0. It appears there's consensus to rip it out which, in my prior
post, I was all for if people felt it meant getting it right.
The thing is that there's nothing here that would improve with time.
Pushing in to 6.0 is basically throwing it out forever, since there's
nothing we could do in 6.0 that we can't do now, there's nothing that we
could do "only if we had time", and only thing will happen towards the
release of 6.0 is that we will repeat the whole story again. I don't see
how anything will change in 6.0 from now except that it will happen in
2-3 years, so in the meantime PHP would miss a feature much needed, much
advertised and much supported by the user base.
We are at the point we just need to take decision. I understand the
natural tendency of people to avoid taking complicated decisions by
postponing the problem, but if you are not ready to take the
responsibility, please do not try to put is as any kind of decision. It
is not. If you don't know what to do with it, if you don't understand
the feature, if you don't feel comfortable with deciding how it should
be - don't say "let's throw it off", it is not a constructive approach.
There's nothing that will change from now to 6.0 except that the people
who worked a lot on this feature would be less ready to repeat the
ordeal. So please do not allow inability to take decision and
unwillingness to address the problem to deprive PHP users of much needed
functionality.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi Stas,
The thing is that there's nothing here that would improve with time.
Except the chance to test approaches that are currently only theories.
Pushing in to 6.0 is basically throwing it out forever, since there's
nothing we could do in 6.0 that we can't do now, there's nothing that we
could do "only if we had time", and only thing will happen towards the
release of 6.0 is that we will repeat the whole story again.
Not so, most of it's there, agreed and tested. What there is, is already in
PHP 6.
I don't see
how anything will change in 6.0 from now except that it will happen in 2-3
years,
I would hope it would happen from the moment 5.3 is out of the door, not
at the last moment before the 6.0 release!
so in the meantime PHP would miss a feature much needed, much advertised
and much supported by the user base.
We are at the point we just need to take decision. I understand the
natural tendency of people to avoid taking complicated decisions by
postponing the problem, but if you are not ready to take the
responsibility, please do not try to put is as any kind of decision.
This was one of the four options we were given. Just because you don't like
it, doesn't mean there are now only three.
It is not. If you don't know what to do with it, if you don't understand
the feature, if you don't feel comfortable with deciding how it should
be - don't say "let's throw it off", it is not a constructive approach.
There's nothing that will change from now to 6.0 except that the people
who worked a lot on this feature would be less ready to repeat the ordeal.
This is very negative, Stas. "Everybody wants it so let's push it out
without testing". Do you really want a repeat of 5.0?
So please do not allow inability to take decision and unwillingness to
address the problem to deprive PHP users of much needed functionality.
Please don't go emotional on us :)
- Steph
Guys, a recomandation (about namespaces):
- if it's not tested enough, don't include it in the release.
- if it's going to make a lot of confusion, don't include it in the
release.
- if neither of the two above won't stop it being included,
and if there aren't 3 quarters (75%) of developers willing to accept
namespaces,
don't include it in the release.
- in short, whatever feature that may cause more headaches or
doesn't have
any real support in the developer community should not be packed for a
release.
Those were my 2 cents ...
Yours,
Catalin Z. Alexandru
-----Original Message-----
From: Steph Fox [mailto:steph@php.net]
Sent: Tuesday, October 14, 2008 8:47 PM
To: Stanislav Malyshev; internals@lists.php.net
Subject: Re: [PHP-DEV] namespaces and alpha3Hi Stas,
The thing is that there's nothing here that would improve with time.
Except the chance to test approaches that are currently only theories.
Pushing in to 6.0 is basically throwing it out forever, since there's
nothing we could do in 6.0 that we can't do now, there's nothing that
we
could do "only if we had time", and only thing will happen towards the
release of 6.0 is that we will repeat the whole story again.Not so, most of it's there, agreed and tested. What there is, is already
in
PHP 6.I don't see
how anything will change in 6.0 from now except that it will happen in
2-3
years,I would hope it would happen from the moment 5.3 is out of the door,
not
at the last moment before the 6.0 release!so in the meantime PHP would miss a feature much needed, much
advertised
and much supported by the user base.
We are at the point we just need to take decision. I understand the
natural tendency of people to avoid taking complicated decisions by
postponing the problem, but if you are not ready to take the
responsibility, please do not try to put is as any kind of decision.This was one of the four options we were given. Just because you don't
like
it, doesn't mean there are now only three.It is not. If you don't know what to do with it, if you don't
understand
the feature, if you don't feel comfortable with deciding how it should
be - don't say "let's throw it off", it is not a constructive
approach.
There's nothing that will change from now to 6.0 except that the
people
who worked a lot on this feature would be less ready to repeat the
ordeal.This is very negative, Stas. "Everybody wants it so let's push it out
without testing". Do you really want a repeat of 5.0?So please do not allow inability to take decision and unwillingness to
address the problem to deprive PHP users of much needed functionality.Please don't go emotional on us :)
- Steph
Hi!
This is very negative, Stas. "Everybody wants it so let's push it out
without testing". Do you really want a repeat of 5.0?
Nobody talks about "without testing", we are in alpha. But I'm talking
about working on it, not pushing it under the carpet and hoping it
somehow gets better there. I am working on it, so do other people, but
chanting "let's remove it" is not working. If anything is "negative",
this is.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi,
Nobody talks about "without testing", we are in alpha. But I'm talking
about working on it, not pushing it under the carpet and hoping it somehow
gets better there. I am working on it, so do other people, but chanting
"let's remove it" is not working. If anything is "negative", this is.
We are in alpha indeed, and still looking at proposals, and still without
consensus. The last thing I'd want is to see namespace support pushed under
the carpet, but I'd rather see it at this stage of development as part of
the PHP 6 development cycle (as originally planned) than in the 5.3
development cycle (where it probably doesn't belong anyway). It's become
clear that there can't simply be a 'class-only' version in 5.3 without
planning for potential extension of that in 6.0, and in fact that's the
sticking point. We're trying to second-guess forward compatibility for
something that doesn't yet exist in its final form. To me at least, that
means namespace support is starting to look less and less feasible for 5.3
unless we can agree to never extend namespace support beyond classes. Which
we don't.
- Steph
Hi!
We are in alpha indeed, and still looking at proposals, and still
without consensus. The last thing I'd want is to see namespace support
pushed under the carpet, but I'd rather see it at this stage of
development as part of the PHP 6 development cycle (as originally
Why? What would happen then that can't happen now?
in its final form. To me at least, that means namespace support is
starting to look less and less feasible for 5.3 unless we can agree to
never extend namespace support beyond classes. Which we don't.
We could agree on anything, if we only actually worked on agreeing,
instead of working on it not happening. I am really surprised why you
put so much effort into trying to undo the much needed feature.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stas,
We are in alpha indeed, and still looking at proposals, and still without
consensus. The last thing I'd want is to see namespace support pushed
under the carpet, but I'd rather see it at this stage of development as
part of the PHP 6 development cycle (as originallyWhy? What would happen then that can't happen now?
What would happen if we give the namespace implementation a chance to mature
is that it can be delivered as a fully-fledged language element rather than
a partially-fledged and potentially flawed one.
in its final form. To me at least, that means namespace support is
starting to look less and less feasible for 5.3 unless we can agree to
never extend namespace support beyond classes. Which we don't.We could agree on anything, if we only actually worked on agreeing,
instead of working on it not happening. I am really surprised why you put
so much effort into trying to undo the much needed feature.
Not trying to undo it, just trying to prevent a horrible mistake being made
under pressure. If I were trying to undo it, I'd be against namespace
support in PHP 6 rather than suggesting its development belongs there!
- Steph
Hi!
What would happen if we give the namespace implementation a chance to
mature is that it can be delivered as a fully-fledged language element
rather than a partially-fledged and potentially flawed one.
What do you mean by "chance to mature"? Only chance for it to mature is
people actually starting using it and not another week of discussing
separators on internals. And people can't start using it if it's not
only not released but there are developers rooting for it to be removed.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
What would happen if we give the namespace implementation a chance to
mature is that it can be delivered as a fully-fledged language element
rather than a partially-fledged and potentially flawed one.What do you mean by "chance to mature"? Only chance for it to mature is
people actually starting using it and not another week of discussing
separators on internals.
OK, bad choice of terminology. I really mean "a chance for the likelier
problems to be ironed out".
And people can't start using it if it's not only not released but there
are developers rooting for it to be removed.
Suddenly nobody uses CVS? I think if we were to ask explicitly for namespace
testers on php.net once there's a full implementation we're all reasonably
happy with, we'd find them.
- Steph
Hi!
What would happen if we give the namespace implementation a chance to
mature is that it can be delivered as a fully-fledged language element
rather than a partially-fledged and potentially flawed one.What do you mean by "chance to mature"? Only chance for it to mature is
people actually starting using it and not another week of discussing
separators on internals. And people can't start using it if it's not only
not released but there are developers rooting for it to be removed.
There is a way to make both: have people use them, and not commit to BC or
changes in 5.4 or a future release.
Introduce E_EXPERIMENTAL as part of E_ALL. Make it the counterpart of
E_STRICT.
E_STRICT is reserved for deprecated features, and E_EXPERIMENTAL would
complete this idea by letting us push experimental features such as
namespaces (and any other extensions marked as "EXPERIMENTAL" in the manual)
and have people play with them, so the core devs can get the feedback they
need and improve or remove the feature in a future release.
Have namespace related features throw E_EXPERIMENTAL warnings to people so
they are aware this feature may not be present in a future release, or
present but in another form.
Regards, Stan Vassilev
We are in alpha indeed, and still looking at proposals, and still
without consensus. The last thing I'd want is to see namespace
support pushed under the carpet, but I'd rather see it at this
stage of development as part of the PHP 6 development cycle (as
originallyWhy? What would happen then that can't happen now?
What would happen if we give the namespace implementation a chance
to mature is that it can be delivered as a fully-fledged language
element rather than a partially-fledged and potentially flawed one.
Ok, lets slow down here for a second.
We have 4 options. We know how things are without namespaces, we know
how things are with the current implementation. This essentially
leaves 2 choices that are untested for now.
Both of these approaches have some uncleanness to them. If functions
and constants get pushed to the global namespace while classes end up
in the current namespace on include it can lead to some surprises. At
the same time offering an ambiguous syntax to solve ambiguity when it
occurs is also not beautiful. If we try out one of them in alpha3 and
are unhappy I would not want an alpha4 to try out yet another one. But
we will have the alpha3 either way at this point. So we could say lets
try out the one that most people prefer for alpha3. If it sucks, we
kick it out and move on.
Then we can alternatively push it to PHP 6 or drop the idea all
together. I know that Dmitry and Greg were both thinking over
alternative approaches, which did not yet come to a conclusion. Most
of that revolves around other separators between or around namespaces.
So we can keep cooking that.
Namespaces have turned out to be insanely complex. However it seems to
me like most people that are voting are doing this on the basis that
they feel that the problem itself is not yet understood by Stas/
Dmitry. I think they do understand the issue. That being said Greg
also understands the issues well and disagrees with Stas, however I
will leave it to him to decide on how to voice his concerns if at all.
I am sure several other people on this list have followed the
discussions close enough to be able to cast an educated vote. However
if you do not understand the issues do not vote (I do of course not
know who has been following the discussion or has not, so its up to
each person to decide if they are in the loop enough to vote), unless
you simply generally mistrust the approach taken to get to this point
or the people involved.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi Lukas,
We have 4 options. We know how things are without namespaces, we know how
things are with the current implementation. This essentially leaves 2
choices that are untested for now.
True, true.
Both of these approaches have some uncleanness to them. If functions and
constants get pushed to the global namespace while classes end up in the
current namespace on include it can lead to some surprises. At the same
time offering an ambiguous syntax to solve ambiguity when it occurs is
also not beautiful. If we try out one of them in alpha3 and are unhappy I
would not want an alpha4 to try out yet another one. But we will have the
alpha3 either way at this point. So we could say lets try out the one
that most people prefer for alpha3. If it sucks, we kick it out and move
on.
Good thinking - but we'll still see the same arguments even if most of us
think it sucks.
Then we can alternatively push it to PHP 6 or drop the idea all together.
Dropping the idea altogether's unlikely to be an option now.
I know that Dmitry and Greg were both thinking over alternative
approaches, which did not yet come to a conclusion. Most of that revolves
around other separators between or around namespaces. So we can keep
cooking that.
Yeah... I never had a response to ::: so I guess that one's been dumped out
of hand somewhere off-list, but darn I hate -> reuse with a passion!
Namespaces have turned out to be insanely complex. However it seems to me
like most people that are voting are doing this on the basis that they
feel that the problem itself is not yet understood by Stas/ Dmitry.
Far from it. It's more that Stas/Dmitry (and Greg) have invested a lot of
time and thought into the implementation and all three understandably want
to see their work 'out there', whereas I'm far from alone in thinking it's
just not ready to be 'out there' at this stage.
- Steph
Yeah... I never had a response to ::: so I guess that one's been dumped out
of hand somewhere off-list, but darn I hate -> reuse with a passion!
The use of ::: is far to simple. Nobody would want an elegant intuitive
operator that uses 3 colons. 3 colons is just too much to pay for
simplicity :::) I'm holding my +.0001 for something more complex...
didn't someone mention £, €, and ¥ weren't getting enough attention?
Cheers,
Rob.
http://www.interjinn.com
Application and Templating Framework for PHP
I don't think postponing this to another big release is going to do anyone any good. You will not see magical revelations because it's postponed by another year.
Greg, Stas, Dmitry all three have deep understanding of the issues. In fact, I think we are closer to agreeing on a solution than it appears. I believe Dmitry is OK with Stas proposed solution + I think with a few more days of discussions with Greg we can nail something most feel OK with.
Please note that the really important/urgent reasons for why namespaces are needed are resolved. Many of the discussions are around edge cases some of which are not that likely to affect developers on a daily basis. Stas' syntax suggestion for dealing with ambiguous situations will likely almost never be needed. So let's not make an elephant out of it. People who will actually start using this will find it beneficial (and I am sure pick-up will be faster in the OO realm than people here have noted).
Btw, we are still in alpha. Historically a lot of these kind of issues have been resolved towards the end of the alpha cycle. That is OK. The beta/RC cycles are exactly intended to expose serious shortcomings in design with much broader community review.
I can assure you two things though:
a) namespaces are needed by many.
b) We will never make everyone happy.
Andi
Hi Andi,
I don't think postponing this to another big release is going to do anyone
any good. You will not see magical revelations because it's postponed by
another year.
No, but we might see a broader agreement, and that would give more of a
basis for user confidence in moving to namespace usage.
Greg, Stas, Dmitry all three have deep understanding of the issues. In
fact, I think we are closer to agreeing on a solution than it appears. I
believe Dmitry is OK with Stas proposed solution + I think with a few more
days of discussions with Greg we can nail something most feel OK with.
I sincerely hope so.
Please note that the really important/urgent reasons for why namespaces
are needed are resolved. Many of the discussions are around edge cases
some of which are not that likely to affect developers on a daily basis.
Stas' syntax suggestion for dealing with ambiguous situations will likely
almost never be needed. So let's not make an elephant out of it.
Was that pun intentional? :)
People who will actually start using this will find it beneficial (and I am
sure pick-up will be faster in the OO realm than people here have noted).
That would rather depend on whether people like the implementation,
methinks.
Btw, we are still in alpha. Historically a lot of these kind of issues
have been resolved towards the end of the alpha cycle. That is OK. The
beta/RC cycles are exactly intended to expose serious shortcomings in
design with much broader community review.I can assure you two things though:
a) namespaces are needed by many.
b) We will never make everyone happy.
I concur. Just let's not get trapped into one solution while under pressure
at alpha stage, and then be stuck with it forever if it turns out to be less
than optimal.
- Steph
We are in alpha indeed, and still looking at proposals, and still
without consensus. The last thing I'd want is to see namespace
support pushed under the carpet, but I'd rather see it at this
stage of development as part of the PHP 6 development cycle (as
originallyWhy? What would happen then that can't happen now?
What would happen if we give the namespace implementation a chance
to mature is that it can be delivered as a fully-fledged language
element rather than a partially-fledged and potentially flawed one.Both of these approaches have some uncleanness to them. If functions
and constants get pushed to the global namespace while classes end
up in the current namespace on include it can lead to some
surprises. At the same time offering an ambiguous syntax to solve
ambiguity when it occurs is also not beautiful. If we try out one of
them in alpha3 and are unhappy I would not want an alpha4 to try out
yet another one. But we will have the alpha3 either way at this
point. So we could say lets try out the one that most people prefer
for alpha3. If it sucks, we kick it out and move on.
My fear is that once this is in a release (and even if it's just an
alpha), the "public" pressure to keep it will be too big.
Then we can alternatively push it to PHP 6 or drop the idea all
together. I know that Dmitry and Greg were both thinking over
alternative approaches, which did not yet come to a conclusion. Most
of that revolves around other separators between or around
namespaces. So we can keep cooking that.
I believe everyone here will agree that this decision is pretty
crucial. And if Dmitry and Greg have alternative approaches in the
pipeline that need further pondering, then we should wait until they
either finalized their proposals or declared them infeasible themselves.
Why the rush. I really don't understand it. Please, no half-arsed
compromises.
Or, as this little green dude once said, "do, or do not. there is no
try."
- David
I think the three folks understand the sense of urgency to figure this out. They've done a lot of hard work over the past few months to get to this point. I think we're at the last 10 FT now and hopefully within 2-3 days they can come to an agreement. As I mentioned Dmitry is already OK with the current proposal and I think with some additional input from Greg we can figure this out.
Andi
Hi.
Steph Fox wrote:
Not trying to undo it, just trying to prevent a horrible mistake being
made under pressure.
What happened to "release when it is ready"? Who puts up that pressure?
And why is there more pressure for 5.3 to be released than to release
things that people have been hoping and waiting for for years?
Regards,
Karsten
Karsten Dambekalns
FLOW3 & TYPO3 Development
TYPO3 Association
Hi.
Stanislav Malyshev wrote:
This is what I've be fearing. First slated for 5.0. Then 5.3. Now
6.0. It appears there's consensus to rip it out which, in my prior
post, I was all for if people felt it meant getting it right.
If 5.3 is not going to have namespaces, we will remove it's use from
FLOW3 again and will not use them with PHP6 as well. That is because we
can either include it now, or at the next major rewrite of our codebase
(which is years away).
There's nothing that will change from now to 6.0 except that the people
who worked a lot on this feature would be less ready to repeat the
ordeal.
I heartily second that.
Regards,
Karsten
Karsten Dambekalns
FLOW3 & TYPO3 Development
TYPO3 Association