Hi Steph,
[snip]
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?
[/snip]
I don't think Stas is implying not to test it. We are talking about another 5.3 alpha, right? Clearly the beta and RC releases will allow the community to help test and I really do believe this will get a lot of community use in beta/RC mode. What theories are you referring to that need more exploration that can't be done yet for 5.3? Obviously I'm in favor of seeing this in 5.3 but if it does get postponed to 6.0 it would be nice to see a plan of attack for finishing the implementation immediately after the 5.3 release. Without such a plan I fear Stas' prediction of more of nothing will come true.
--Tony
Hi Tony,
I don't think Stas is implying not to test it.
Which proposal do you think he's implying not to test? And which of the
other three proposals on offer do you think should go out there, bearing in
mind that once the thing's released it can't be changed?
- Steph
Steph Fox wrote:
Hi Tony,
I don't think Stas is implying not to test it.
Which proposal do you think he's implying not to test? And which of the
other three proposals on offer do you think should go out there, bearing
in mind that once the thing's released it can't be changed?
I think that is the bottom line!
Can anybody come up with a good case for why functions and constant should be
'thrown out with the bath water' ?
If there is a majority for ignoring a major section of PHP and restricting new
stuff to be only Class based, then we can safely rip functions and constant
out and ignore them and go with the current restricted code?
I get the feeling however that if namespace is to be usable in the SHORT term,
then wrapping functions and constants is essential simply to wrap legacy stuff
while it is converted to objects?
If there was a clear solution to a complete handling of namespace, then there
would not be a problem, but currently there are some big holes that can not be
plugged later if the CURRENT code is released?
So put it back on the drawing board and try and plug the holes rather than
holding up 5.3. While there may have been talking about namespace for years,
the problems were never fully appreciated? Now that they have been documented
and some of the pros and cons discussed, it is clear that a decision to force
the current solution through will cause as many problems later on?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hi!
Can anybody come up with a good case for why functions and constant
should be 'thrown out with the bath water' ?
I can name two:
- Most (not all, I know, but most) of the use cases for namespaces are
in the OO realm, and most of the problems they are to serve come from
that realm too. So at least initially most of the active users, which
wait for it impatiently, are OO users, and classes are the thing the
care the most about. - Everything becomes so much simpler with only classes. Classes and
functions have very different usage patterns in PHP, so if we try to
serve them both we inevitably encounter some "inconsistencies" in how
they are served, because of the different usage patterns, which may be a
problem for some purists. I personally don't care too much for
"inconsistencies" if they serve the user - i.e. allow to do useful
things easier - but I know there are other approaches.
Please note that doesn't mean we must drop them - I am just presenting
the argument for it, I am aware of the existence of the arguments
against too.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I can name two:
- Most (not all, I know, but most) of the use cases for namespaces are in
the OO realm, and most of the problems they are to serve come from that
realm too. So at least initially most of the active users, which wait for
it impatiently, are OO users, and classes are the thing the care the most
about.- Everything becomes so much simpler with only classes. Classes and
functions have very different usage patterns in PHP, so if we try to serve
them both we inevitably encounter some "inconsistencies" in how they are
served, because of the different usage patterns, which may be a problem
for some purists. I personally don't care too much for "inconsistencies"
if they serve the user - i.e. allow to do useful things easier - but I
know there are other approaches.
FWIW, I agree with everything Stas says here.
Please note that doesn't mean we must drop them - I am just presenting
the argument for it, I am aware of the existence of the arguments against
too.
The problem is we can't know whether restricting future evolution in
namespace support is going to turn out to be a good idea.
- Steph
Hi!
The problem is we can't know whether restricting future evolution in
namespace support is going to turn out to be a good idea.
I think we have now all the information we could have without really
having it in the wild. Yes, we can make a mistake based on this
information, but I see no use in sitting there and doing nothing but
asking ourselves "do we make a mistake?". We are not advancing with it
that way. If you can name something that could further our progress here
and that can be done after 5.3 but can't be done right now - name it.
Otherwise I see absolutely no reason in postponing the decision.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
If you can name something that could further our progress here and that
can be done after 5.3 but can't be done right now - name it.
Broad-scale testing with the ability to alter the implementation should
problems become apparent.
Otherwise I see absolutely no reason in postponing the decision.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
Broad-scale testing with the ability to alter the implementation should
problems become apparent.
What you are talking about? Who'll be doing this broad-scale testing, when?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Broad-scale testing with the ability to alter the implementation should
problems become apparent.What you are talking about? Who'll be doing this broad-scale testing,
when?
Users. And I think Lukas' approach is good - use alpha as a testing ground.
- Steph
Hi!
Users. And I think Lukas' approach is good - use alpha as a testing ground.
Namespaces are for big projects. Staring big project using namespaces
when it's not even clear they'll be in 5.3 is an insane risk, nobody
would do it.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Namespaces are for big projects. Staring big project using namespaces when
it's not even clear they'll be in 5.3 is an insane risk, nobody would do
it.
Only 8 hours ago, one Jean-Phillipe Serafin wrote: "Many people have
starting working on top level application using namespaces, so there will a
very bad buzz over the php community if namespaces are ripped out..." and
there were further objections on the grounds that namespace support has been
'announced' on php.net.
I agree with you that it's an insane risk, but that doesn't mean nobody does
it.
- Steph
Hi!
Only 8 hours ago, one Jean-Phillipe Serafin wrote: "Many people have
starting working on top level application using namespaces, so there
will a very bad buzz over the php community if namespaces are ripped
out..." and there were further objections on the grounds that namespace
support has been 'announced' on php.net.
Exactly. This is because we announced it on conferences, talked about it
on lists and basically made a lot of noise about how cool it would be
very soon. And people believed us and took the risk. And now you propose
to teach them the lesson that trusting PHP core developers that they
actually deliver is a bad idea.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stas...
And people believed us and took the risk.
Which you just said they wouldn't do.
And now you propose to teach them the lesson that trusting PHP core
developers that they actually deliver is a bad idea.
It seems a sounder policy than teaching them they can't trust that what is
actually delivered will be robust!
- Steph
Hi!
Only 8 hours ago, one Jean-Phillipe Serafin wrote: "Many people
have starting working on top level application using namespaces, so
there will a very bad buzz over the php community if namespaces are
ripped out..." and there were further objections on the grounds
that namespace support has been 'announced' on php.net.Exactly. This is because we announced it on conferences, talked
about it on lists and basically made a lot of noise about how cool
it would be very soon. And people believed us and took the risk. And
now you propose to teach them the lesson that trusting PHP core
developers that they actually deliver is a bad idea.
just to clarify .. there are solutions on the table that people have
worked on hard and that are believed to solve the issues, albeit that
come with some carefully chosen baggage. We are not discussing how to
do things (this goes to Nathan's reply that just came in). if we
remove namespaces now, after talking about it, prodding it, asking
people to try it out, getting a lot of general positive vibe for this
feature, coming up with a solution .. then i think we are doing our
users a disservices. the proposals are not half baked omg we need to
get this done quickly for alpha3 (note that alpha3 was delayed to get
to this point).
of course waiting longer always gives the opportunity to improve tweak
etc. but given that we might as wel stop releasing software altogether
if we are unwilling to take the risk of a mistake.
anyways, given the current state most people voted to remove
namespaces from PHP 5.3. i assume that all people that casted these
votes were (and still are) confident that they actually know what they
voted on. maybe some of the people involved in finding the current
proposals will try to document the issues and the solution (and the
issues in these solutions) onces more in the hopes of changing the
minds of some of the people that have voted. i personally have spend
enough time on namespaces for now that i will not involve myself in
that any further for now.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
anyways, given the current state most people voted to remove namespaces
from PHP 5.3. i assume that all people that casted these votes were (and
still are) confident that they actually know what they voted on. maybe
some of the people involved in finding the current proposals will try to
document the issues and the solution (and the issues in these solutions)
onces more in the hopes of changing the minds of some of the people that
have voted. i personally have spend enough time on namespaces for now
that i will not involve myself in that any further for now.
I think we should wait and see what Greg et al come up with. If they're
close to a solution they believe will be acceptable to all, we're voting too
soon.
- Steph
anyways, given the current state most people voted to remove
namespaces from PHP 5.3. i assume that all people that casted
these votes were (and still are) confident that they actually know
what they voted on. maybe some of the people involved in finding
the current proposals will try to document the issues and the
solution (and the issues in these solutions) onces more in the
hopes of changing the minds of some of the people that have voted.
i personally have spend enough time on namespaces for now that i
will not involve myself in that any further for now.I think we should wait and see what Greg et al come up with. If
they're close to a solution they believe will be acceptable to all,
we're voting too soon.
err .. you misunderstood me .. Dmitry wasnt happy with his approach ..
last I heard Greg also stopped exploring his alternative approaches.
so dont hold you breath.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
-----Original Message-----
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
Sent: Tuesday, October 14, 2008 2:15 PM
To: Steph Fox
Cc: Stas Malyshev; PHP internals
Subject: Re: [PHP-DEV] namespaces and alpha3err .. you misunderstood me .. Dmitry wasnt happy with his approach ..
last I heard Greg also stopped exploring his alternative approaches.
so dont hold you breath.
As I said, I talked to Dmitry today and he was OK with it.
I do think there's also a good chance to make progress with Greg.
I suggest to give it a couple of more days. In any case, as I said, the
real issues that are being discussed are mostly marginal and I think a
broader alpha/beta when the time comes will help get the necessary
feedback from people who really play around with it and/or bring up
other issues.
Andi
Andi Gutmans schreef:
-----Original Message-----
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
Sent: Tuesday, October 14, 2008 2:15 PM
To: Steph Fox
Cc: Stas Malyshev; PHP internals
Subject: Re: [PHP-DEV] namespaces and alpha3err .. you misunderstood me .. Dmitry wasnt happy with his approach ..
last I heard Greg also stopped exploring his alternative approaches.
so dont hold you breath.As I said, I talked to Dmitry today and he was OK with it.
I do think there's also a good chance to make progress with Greg.
I'd like to reiterate that I gave a +1 on posponing till 6.0.
If it turns out that some form of the latest proposal (by Stas) get's
an OK from Greg then I'd change my vote (for what it's worth) to align
with Greg's ... I followed Greg's analysis and proposed solutions very
closely, if he end's up giving an OK to some form of Stas' latest proposal
then that would likely indicate a situation/feature that is really worth
releasing.
basically: if Greg gives a 'thumbs up' all the nay-sayers should take note!
he was probably the biggest nay-sayer and he did his homework more thoroughly
than just about anyone else I've come accross.
I suggest to give it a couple of more days. In any case, as I said, the
real issues that are being discussed are mostly marginal and I think a
broader alpha/beta when the time comes will help get the necessary
feedback from people who really play around with it and/or bring up
other issues.Andi
Le mardi 14 octobre 2008 à 15:30 -0700, Andi Gutmans a écrit :
err .. you misunderstood me .. Dmitry wasnt happy with his approach ..
last I heard Greg also stopped exploring his alternative approaches.
so dont hold you breath.As I said, I talked to Dmitry today and he was OK with it.
I do think there's also a good chance to make progress with Greg.I suggest to give it a couple of more days. In any case, as I said, the
real issues that are being discussed are mostly marginal and I think a
broader alpha/beta when the time comes will help get the necessary
feedback from people who really play around with it and/or bring up
other issues.
Hi,
I've played a lot with namespaces too, and wrote a new version of some
project I wrote long time ago with namespaces in mind.
Old 99% procedural code, written years ago:
http://ookoo.org/svn/pinetd/
New object code, with namespaces:
http://ookoo.org/svn/pinetd2/
The new code was already started more than one year ago, and had some
updates (eg. import became use), however it still somewhat works (I'm
testing it with php 5.3alpha2, and I'm waiting for PHP 5.3 to be
released before officially announcing the new branch and fixing some of
the remaining bugs, see for example http://bugs.php.net/bug.php?id=46127
which I'd like to see fixed in HEAD/PHP_5_3).
By the way I'd just like to point out that I never ever had to use
functions/defines in namespaces, and don't really care about those
anyway. As far as I understand it, namespaces are an oop element, and
shouldn't affect non-oo programming. Because of this, the only real
change I had to follow was when "use" replaced "import".
Anyway I had a few other ideas related to namespaces I posted here
before, but got no feedback, so I'll just continue to use this in my own
php versions; and that's all.
Mark
-----Original Message-----
From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
Sent: Tuesday, October 14, 2008 2:15 PM
To: Steph Fox
Cc: Stas Malyshev; PHP internals
Subject: Re: [PHP-DEV] namespaces and alpha3err .. you misunderstood me .. Dmitry wasnt happy with his approach ..
last I heard Greg also stopped exploring his alternative approaches.
so dont hold you breath.As I said, I talked to Dmitry today and he was OK with it.
I do think there's also a good chance to make progress with Greg.
Thats awesome.
By the way, what is "it"?
I haven't had the chance of following the hundreds of namespaces
threads with thousands of replies. All I have gather so far is a
massive amount of FUD.
Could someone summarize what you are trying to convince Greg to agree
on? I would greatly appreciate if that post would not get +100 replies
under an hour.
-Hannes
Thats awesome.
By the way, what is "it"?
I haven't had the chance of following the hundreds of namespaces
threads with thousands of replies. All I have gather so far is a
massive amount of FUD.Could someone summarize what you are trying to convince Greg to agree
on? I would greatly appreciate if that post would not get +100 replies
under an hour.-Hannes
Have to agree on the FUD thing - how many people commenting on this
thread have actually tried the current namespaces implementation for
themselves? Or are they simply parroting what they've read or what
others have said? Maybe a prerequisite for any kind of vote should
include actual code written using namespaces.
And yes, I have some sitting around in public svn ;) But I'm not crass
enough to spam the list with the url, email me privately if you want to
see it.
I use to have many issues with namespaces - compromises and good code
have knocked off most of the problems and I'm almost happy.
I really only have one issue left with namespaces. This remaining issue
is of course the "is it a method or is a function" problem
foo::bar::baz(); - is this calling function baz in namespace foo::bar?
or is it calling static method bar::baz in namespace foo?
This can be solved in three ways.
- Greg's "leaf" solution
foo::bar->baz(); - namespace foo::bar, function baz
foo->bar::baz(); - namespace foo, static method bar::baz
Personally I don't like this, get confusing even if we pick some weird
operator like :>
- Don't allow functions or constants in namespaces
Simplest solution but appears to piss off all the people who have never
actually used the current implementation or hate OO on principle
- Steph's idea - Change the separator (I vote ':::' - easy to do,
similar to what we have already)
foo:::bar:::baz(); - namespace foo:::bar function baz
foo:::bar::baz(); - namespace foo, static method bar::baz
I like this too, minus the headache of arguing over the namespace
separator (again) - in a perfect world this would be a single colon, but
the ternary issues (people write stupid code, so we have to cater to
them) strikes again.
$foo = $myvar ? foo:bar:hello; - craziness, although personally I'd say
"always take the last :" for issues like this and document the hell out
of it...
$foo = $myvar ? (foo:bar):hello; or $foo = $myvar ? foo:(bar:hello);
should give you the right thing...
But I digress. I know a lot of people are simply filtering out the
namespace "noise" or are "voting on gut reactions" - "OMG the people who
write the code are arguing, it must totally suck" ...
Write some code using the current namespaces implementation. Functional
and OO. Then decide, don't listen to people bitching or wait for
someone else to summarize issues they've found. People not trying it
are how we got into this mess in the first place.
Thanks,
Elizabeth Smith
Hi Elizabeth,
This can be solved in three ways.
- Greg's "leaf" solution
foo::bar->baz(); - namespace foo::bar, function baz
foo->bar::baz(); - namespace foo, static method bar::bazPersonally I don't like this, get confusing even if we pick some weird
operator like :>
- Don't allow functions or constants in namespaces
Simplest solution but appears to piss off all the people who have never
actually used the current implementation or hate OO on principle
Nope, it's more the case that if we don't allow it we have to either say
'never' or set up an environment whereby functions and constants could be
supported at a later date if need be.
- Steph's idea - Change the separator (I vote ':::' - easy to do,
similar to what we have already)
foo:::bar:::baz(); - namespace foo:::bar function baz
foo:::bar::baz(); - namespace foo, static method bar::bazI like this too, minus the headache of arguing over the namespace
separator (again) - in a perfect world this would be a single colon, but
the ternary issues (people write stupid code, so we have to cater to
them) strikes again.
Actually that wasn't what I meant. I meant take Greg's "leaf" solution
(huh?) without the ambiguous -> part for namespace elements, and yes I'd
prefer : for this too but that's dead in the water. So:
foo:::bar->baz(); - namespace foo, namespace element bar->baz();
foo:::bar::baz(); - namespace foo, namespace element bar::baz();
foo:::baz(); - namespace foo, namespace element baz();
foo::bar::baz:::bat->fez(); - nested namespaces foo, bar, baz, namespace
element bat->fez();
::baz(); - global element called within namespaced code
Those last two work out fine because :: is a scoping operator, not
class-specific (which point it took me a while to get my head around). I
think Greg's T_NS_MEMBER was the best idea ever for dealing with this
sanely, he just did it so quietly we didn't notice:
http://marc.info/?l=php-internals&m=122265715319308&w=2, and read all the
way to the end. Taking ns elements and scope as different principles means
we never get the 'dots before the eyes' issue that caused ::: to be turned
down in the first place.
Derick won't like ::baz() though.
- Steph
Hi!
This can be solved in three ways.
Somehow you did not mention my idea of using foo::bar->baz() for method
call. Was it because you don't like it? If so, why?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
Hi!
This can be solved in three ways.
Somehow you did not mention my idea of using foo::bar->baz() for method
call. Was it because you don't like it? If so, why?
Probably because I missed it in the noise - only it would still lead to
ambiguity issues if you have a namespace foo::bar; and a class foo::bar
with a regular method baz. So ...still doesn't solve the problem.
elizabeth
Elizabeth M Smith wrote:
<snip>
This can be solved in three ways.
- Greg's "leaf" solution
foo::bar->baz(); - namespace foo::bar, function baz
foo->bar::baz(); - namespace foo, static method bar::bazPersonally I don't like this, get confusing even if we pick some weird
operator like :>
- Don't allow functions or constants in namespaces
Simplest solution but appears to piss off all the people who have never
actually used the current implementation or hate OO on principle
- Steph's idea - Change the separator (I vote ':::' - easy to do,
similar to what we have already)
foo:::bar:::baz(); - namespace foo:::bar function baz
foo:::bar::baz(); - namespace foo, static method bar::baz
Honestly, either the tough choices must be made soon or namespaces has
to be held until 6. IMO
From my experience using namespaces #1 AND #2 would make namespaces
solid (again IMO). The only thing for #1 is that I wouldn't want to see
-> reused, as others have mentioned. Maybe :> or something else. Same
for #3, :: just causes confusion. I don't really care what it's changed
to, ::: is fine, it just cannot be ::
Take a look at what autoload gets when an undeclared namespace, class,
whatever is called. That will give you the idea on how autoload doesn't
really know what is being called. With the change in #3 and addition of
#1, it would be possible to know what is being called.
If all issues are evolved to reusing same operator, :: ...
Why is it so complicated to change the separator and get everything supported?
Is that too hard?
+3 for Liz option #3. Long live :::!
[]s,
Elizabeth M Smith wrote:
<snip>This can be solved in three ways.
- Greg's "leaf" solution
foo::bar->baz(); - namespace foo::bar, function baz
foo->bar::baz(); - namespace foo, static method bar::bazPersonally I don't like this, get confusing even if we pick some weird
operator like :>
- Don't allow functions or constants in namespaces
Simplest solution but appears to piss off all the people who have never
actually used the current implementation or hate OO on principle
- Steph's idea - Change the separator (I vote ':::' - easy to do,
similar to what we have already)
foo:::bar:::baz(); - namespace foo:::bar function baz
foo:::bar::baz(); - namespace foo, static method bar::bazHonestly, either the tough choices must be made soon or namespaces has to be
held until 6. IMOFrom my experience using namespaces #1 AND #2 would make namespaces solid
(again IMO). The only thing for #1 is that I wouldn't want to see -> reused,
as others have mentioned. Maybe :> or something else. Same for #3, :: just
causes confusion. I don't really care what it's changed to, ::: is fine, it
just cannot be ::Take a look at what autoload gets when an undeclared namespace, class,
<rant> Seriously, why is changing :: seem like such a problem?
whatever is called. That will give you the idea on how autoload doesn't
really know what is being called. With the change in #3 and addition of #1,
it would be possible to know what is being called.--
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil
On Wed, Oct 15, 2008 at 3:49 PM, Guilherme Blanco <guilhermeblanco@gmail.com
wrote:
If all issues are evolved to reusing same operator, :: ...
Why is it so complicated to change the separator and get everything
supported?
Is that too hard?+3 for Liz option #3. Long live :::!
[]s,
Elizabeth M Smith wrote:
<snip>This can be solved in three ways.
- Greg's "leaf" solution
foo::bar->baz(); - namespace foo::bar, function baz
foo->bar::baz(); - namespace foo, static method bar::bazPersonally I don't like this, get confusing even if we pick some weird
operator like :>
- Don't allow functions or constants in namespaces
Simplest solution but appears to piss off all the people who have never
actually used the current implementation or hate OO on principle
- Steph's idea - Change the separator (I vote ':::' - easy to do,
similar to what we have already)
foo:::bar:::baz(); - namespace foo:::bar function baz
foo:::bar::baz(); - namespace foo, static method bar::bazHonestly, either the tough choices must be made soon or namespaces has to
be
held until 6. IMOFrom my experience using namespaces #1 AND #2 would make namespaces solid
(again IMO). The only thing for #1 is that I wouldn't want to see ->
reused,
as others have mentioned. Maybe :> or something else. Same for #3, ::
just
causes confusion. I don't really care what it's changed to, ::: is fine,
it
just cannot be ::Take a look at what autoload gets when an undeclared namespace, class,
<rant> Seriously, why is changing :: seem like such a problem?
whatever is called. That will give you the idea on how autoload doesn't
really know what is being called. With the change in #3 and addition of
#1,
it would be possible to know what is being called.--
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil--
Or even
use my::cool::namespace#GregsNamespaceElement
I couldn't understand why Greg's proposal wasn't accepted...
--
Diego Feitosa
www.dnfeitosa.com
Caelum - Ensino e Soluções em Java
diego.feitosa@caelum.com.br
www.caelum.com.br
2008/10/15 Diego Feitosa dnfeitosa@gmail.com:
<snip>
Or even
use my::cool::namespace#GregsNamespaceElement
Because # is a comment, other solutions for unused operators is a
better choice IF the double colon operator has to be changed in
namespaces.
I couldn't understand why Greg's proposal wasn't accepted...
--
Diego Feitosa
www.dnfeitosa.comCaelum - Ensino e Soluções em Java
diego.feitosa@caelum.com.br
www.caelum.com.br
--
Kalle Sommer Nielsen
Hi!
Could someone summarize what you are trying to convince Greg to agree
on? I would greatly appreciate if that post would not get +100 replies
under an hour.
My proposals are here:
http://wiki.php.net/rfc/namespaceref
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi,
My proposals are here:
http://wiki.php.net/rfc/namespaceref
Just for the record: I like both of them, the second one would probably
be better to accomodate those who want functions in namespaces.
Regards,
Christian
2008/10/14 Steph Fox steph@php.net:
Only 8 hours ago, one Jean-Phillipe Serafin wrote: "Many people have
starting working on top level application using namespaces, so there will a
very bad buzz over the php community if namespaces are ripped out..." and
there were further objections on the grounds that namespace support has been
'announced' on php.net.
I'd like to point out that those people started working with
namespaces before the idea of dropping them (or postponing them to
PHP 6) appeared on the list. I doubt those people would have done the
same if they had been told that namespaces may very well not be
available until PHP 6.
Namespace support in 5.3 received quite a lot of coverage this year
through blogs, articles and presentations, that's why some people
started implementing them or prepared to migrate their codebase. Now
if they're told it's postponed indefinitely (until PHP 6 gets a
tentative schedule) they'll feel burned and they'll think twice before
investing any time in testing new features in future releases.
I think that's what Stas meant, people would not take the risk to
implement such extensive changes without the assurance that namespace
will be available. Those who already did were pretty sure that 5.3
would have namespaces.
JD
Hi Josh,
I'd like to point out that those people started working with
namespaces before the idea of dropping them (or postponing them to
PHP 6) appeared on the list. I doubt those people would have done the
same if they had been told that namespaces may very well not be
available until PHP 6.
Surely everyone can see the very public ongoing discussions on internals@
over the course of this and last year?
Namespace support in 5.3 received quite a lot of coverage this year
through blogs, articles and presentations, that's why some people
started implementing them or prepared to migrate their codebase. Now
if they're told it's postponed indefinitely (until PHP 6 gets a
tentative schedule) they'll feel burned and they'll think twice before
investing any time in testing new features in future releases.
There's a very big difference between 'testing' and 'preparing to migrate a
codebase'.
I think that's what Stas meant, people would not take the risk to
implement such extensive changes without the assurance that namespace
will be available. Those who already did were pretty sure that 5.3
would have namespaces.
And of course those same people don't mind a bit if the implementation has
changed 8 times in the last 6 months, because they understand that they're
testing a moving target. No?
- Steph
Hi!
Surely everyone can see the very public ongoing discussions on
internals@ over the course of this and last year?
Surely everyone in PHP world reads internals@ and can follow all the
twists and turns of all the discussion. You must be kidding.
And of course those same people don't mind a bit if the implementation
has changed 8 times in the last 6 months, because they understand that
they're testing a moving target. No?
It wasn't changed in any substantial way even 2 times, let's not
exaggerate. And most things under discussion now - except for removing
functions which 99% of these people don't need anyway - are very special
cases which while exist theoretically are easily avoided in practical
code by following code style guidelines, thus ensuring whatever comes
out would not have critical influence on the code.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
Hi!
Surely everyone can see the very public ongoing discussions on
internals@ over the course of this and last year?Surely everyone in PHP world reads internals@ and can follow all the
twists and turns of all the discussion. You must be kidding.
most of the frequenters of @general do
Hi!
Surely everyone can see the very public ongoing discussions on internals@over the course of this and last year?
Surely everyone in PHP world reads internals@ and can follow all the
twists and turns of all the discussion. You must be kidding.
I think the same - the noise was high, many people know that "namespaces are
coming". I personally tried to follow all of the threads on the namespace
discussions @internals in the last years, but honestly - I couldn't. From my
personal statistics - almost no developers (as % from the total) outside the
"php core team" could/had the time.
And of course those same people don't mind a bit if the implementation has
changed 8 times in the last 6 months, because they understand that they're
testing a moving target. No?It wasn't changed in any substantial way even 2 times, let's not
exaggerate. And most things under discussion now - except for removing
functions which 99% of these people don't need anyway - are very special
cases which while exist theoretically are easily avoided in practical code
by following code style guidelines, thus ensuring whatever comes out would
not have critical influence on the code.
I've implemented several projects using namespaces; a complex use - with
autoload, file hierarchy corresponding to the namespace one, with namespaced
constants and functions, and nothing was broken while I was updating the
php5.3-dev, so looks like nothing major (related to ns) was changed.
"...are easily avoided in practical code by following code style guidelines"
- I think this can be applied to the current implementation and just avoid
naming static class and a namespace in with repeating names (in the same
position in the hierarchy), to avoid the ambiguity, can it?
Last thought - now php5.3 is in alpha release stage - what is the better
time to try something new? Change the proposal to whatever you find is best
and release it. But posponing it the opportunity will be missed (until the
next one of php6 alpha cycle when the situation will be repeated). Steph, I
see you point (thank you for the exmplanation), I just think that whatever
the solution is will be better to have something in the alpha at least to
gather feedback.
Someone in the previous messages said that he is affraid that after the
release in the alpha of a not-so-good-namespace-implementation there might
be public pressure to preserve it. But I think this is not that bad, because
means that the developers liked it.
In short - use the alpha cycle to propose solutions even if they get
scrapped at the end. At least you will know what is not working (wheter for
technical or human reasons) and then a better implementation can be proposed
for 6.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com--
--
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com
Hi.
Steph Fox wrote:
Surely everyone can see the very public ongoing discussions on
internals@ over the course of this and last year?
Sure. No?
There's a very big difference between 'testing' and 'preparing to
migrate a codebase'.
Ok, but the broad testing needs a broad scope. We need more than
10-liners to check namespaces. No?
And of course those same people don't mind a bit if the implementation
has changed 8 times in the last 6 months, because they understand that
they're testing a moving target. No?
Moving targets that suddenly just evaporate into nothingness are
somewhat different. No?
Trying to be cynical,
Karsten
Karsten Dambekalns
FLOW3 & TYPO3 Development
TYPO3 Association
People, why you just don't change the namespace separator to something
except :: and sole all the problems one and for all? God damn, use :> if you
need - just push it out working! Most of my fellow programmers are just sick
with reading internals discussing how to throw a feathure away because
ambitity problem with :: can't be solved totaly. Me too, mostly I just skip
namespace topics.
Make a solid decision. Find the guts to change that misserable :: separator
to something else (:> for example) and be done with it - you are like
children who can't deside whose toy is it with thouse namespaces! Take a
break for 2-3 days and look back on what you are arguing about - you made a
problem from nothing! Originaly no one thought about :: can be used with
namespaces,now you are trying to fix it but you can't.This is a design
issue, you can't solve it without breaking BC and getting everybody happy.
By changing separator you will reach all goals at one shot - functions,
classes, constants will be alowed in namespaces. That is what userland
developers what. Give that to them!
I recommend you and your fellow programmers read the discussion again.
It's nost just about syntax.
People, why you just don't change the namespace separator to something
except :: and sole all the problems one and for all? God damn,
use :> if you
need - just push it out working! Most of my fellow programmers are
just sick
with reading internals discussing how to throw a feathure away because
ambitity problem with :: can't be solved totaly. Me too, mostly I
just skip
namespace topics.Make a solid decision. Find the guts to change that misserable ::
separator
to something else (:> for example) and be done with it - you are like
children who can't deside whose toy is it with thouse namespaces!
Take a
break for 2-3 days and look back on what you are arguing about - you
made a
problem from nothing! Originaly no one thought about :: can be used
with
namespaces,now you are trying to fix it but you can't.This is a design
issue, you can't solve it without breaking BC and getting everybody
happy.By changing separator you will reach all goals at one shot -
functions,
classes, constants will be alowed in namespaces. That is what userland
developers what. Give that to them!