Hi!
I has been almost a month since we did our routine talk about 5.4, so
here it goes again. The patch for the scalar hints seems to be pretty
simple (see http://random-bits-of.info/no_scalar_hints.diff - no
generated files included, that will be done on actual commit), so it
should not hold us too much.
I propose putting current code in a branch and continue without scalar
typing for 5.4 - any objections to that?
I would like to propose the following process (of course, dates can be
moved around, etc. - I consider phase lengths be more important that
actual dates, but any of them can be shifted if reason arises) for 5.4:
- starting now - nominate features for 5.4 (see
https://wiki.php.net/todo/php54), discussion on them - May 18 - start voting and debating on features that have no clear
consensus support immediately. On the end of May is also phptek, so we
could have some discussion there about it if needed. - June 15 (a bit more than a month) - alpha, branching of 5_4, open only
for bugfixes and features in TODO list that are approved and can be done
by beta time. - July 20 - beta, bugfixes only (if we add a lot of features, we may
want to insert another 1-month alpha period, so far it doesn't look like
it but may change) - Aug 24 - RC1, then an RC every 2 weeks until stable
- Release - somewhere in October or November, depending on the RCs.
I think we need to start moving. Not much is happening in 5.4 now as far
as I can see, and we have a good feature set that is long due to be
released.
For proposing stuff for 5.4, please do it here:
https://wiki.php.net/todo/php54 and also on the list if it wasn't
discussed and you think it requires discussion.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
I has been almost a month since we did our routine talk about 5.4, so
here it goes again. The patch for the scalar hints seems to be pretty
simple (see http://random-bits-of.info/no_scalar_hints.diff - no
generated files included, that will be done on actual commit), so it
should not hold us too much.
I propose putting current code in a branch and continue without scalar
typing for 5.4 - any objections to that?I would like to propose the following process (of course, dates can be
moved around, etc. - I consider phase lengths be more important that
actual dates, but any of them can be shifted if reason arises) for 5.4:
- starting now - nominate features for 5.4 (see
https://wiki.php.net/todo/php54), discussion on them- May 18 - start voting and debating on features that have no clear
consensus support immediately. On the end of May is also phptek, so we
could have some discussion there about it if needed.- June 15 (a bit more than a month) - alpha, branching of 5_4, open only
for bugfixes and features in TODO list that are approved and can be done
by beta time.- July 20 - beta, bugfixes only (if we add a lot of features, we may
want to insert another 1-month alpha period, so far it doesn't look like
it but may change)- Aug 24 - RC1, then an RC every 2 weeks until stable
- Release - somewhere in October or November, depending on the RCs.
I think we need to start moving. Not much is happening in 5.4 now as far
as I can see, and we have a good feature set that is long due to be
released.
For proposing stuff for 5.4, please do it here:
https://wiki.php.net/todo/php54 and also on the list if it wasn't
discussed and you think it requires discussion.
Looks good to me.
I see the array shortcuts are on your todo discussion list there. We
probably shouldn't get into a full discussion on that since it will span
hundreds of messages. But if any of the folks who voted no last time
around have changed their minds, it would be good to know. And before
deciding, try using MongoDB from PHP for a couple of weeks. :)
-Rasmus
I has been almost a month since we did our routine talk about 5.4, so
here it goes again. The patch for the scalar hints seems to be pretty
simple (see http://random-bits-of.info/no_scalar_hints.diff - no
generated files included, that will be done on actual commit), so it
should not hold us too much.
I propose putting current code in a branch and continue without scalar
typing for 5.4 - any objections to that?I would like to propose the following process (of course, dates can be
moved around, etc. - I consider phase lengths be more important that
actual dates, but any of them can be shifted if reason arises) for 5.4:
- starting now - nominate features for 5.4 (see
https://wiki.php.net/todo/php54), discussion on them- May 18 - start voting and debating on features that have no clear
consensus support immediately. On the end of May is also phptek, so we
could have some discussion there about it if needed.- June 15 (a bit more than a month) - alpha, branching of 5_4, open only
for bugfixes and features in TODO list that are approved and can be done
by beta time.- July 20 - beta, bugfixes only (if we add a lot of features, we may
want to insert another 1-month alpha period, so far it doesn't look like
it but may change)- Aug 24 - RC1, then an RC every 2 weeks until stable
- Release - somewhere in October or November, depending on the RCs.
I think we need to start moving. Not much is happening in 5.4 now as far
as I can see, and we have a good feature set that is long due to be
released.
For proposing stuff for 5.4, please do it here:
https://wiki.php.net/todo/php54 and also on the list if it wasn't
discussed and you think it requires discussion.Looks good to me.
I see the array shortcuts are on your todo discussion list there. We
probably shouldn't get into a full discussion on that since it will span
hundreds of messages. But if any of the folks who voted no last time around
have changed their minds, it would be good to know. And before deciding, try
using MongoDB from PHP for a couple of weeks. :)
maybe it would be a good idea to gather the pros/cons which was brought up
in the last discussion/poll.
another thing that I would love to see on the list: named parameters.
it was recently brought up, and I think that the original argument for the
rejection isn't true anymore:
http://www.php.net/~derick/meeting-notes.html#named-parameters
adding naming parameters would actually help to make clean and maintainable
code.
currently if you want optional params, you either have to create long list
of arguments with default values, and call your functions like
-$foo->bar($a, $b, NULL, NULL, false, $c), or you have to put your argument
into an array/object and pass that to your function, which pretty much
defeats the purpose.
I don't propose that we should hold up the release process with that, but we
should at least consider it for inclusion.
what do you think?
Tyrael
Hi!
another thing that I would love to see on the list: named parameters.
it was recently brought up, and I think that the original argument for
the rejection isn't true anymore:
http://www.php.net/~derick/meeting-notes.html#named-parameters
adding naming parameters would actually help to make clean and
maintainable code.
I'm all for this idea, but the question is - can we have a good design &
implementation in next 2 months? If we can, great, if we can't - I'd
rather have 5.4 than wait for it. E.g., if we have somebody ready to
commit for certain timeframe to come up with it, then it makes sense to
discuss it in this context.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi:
I'm all for this idea, but the question is - can we have a good design & implementation in next 2 months? If we can, great, if we can't - I'd rather have 5.4 than wait for it. E.g., if we have somebody ready to commit for certain timeframe to come up with it, then it makes sense to discuss it in this context.
Can't we just draw this arbitrary line in the sand, and say from now on, controversial things are taken out and nothing new is added anymore?
Everything which is not yet in trunk and is not required to round up the release should go into the release after 5.4?
For me it seems there is no progress because there is still to much opportunity to improve things...
So, instead of allowing to nominate new features, it might be best to stick to what we have now, and restrict ourselves to sort out the controversial stuff.
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
Hi:
I'm all for this idea, but the question is - can we have a good design &
implementation in next 2 months? If we can, great, if we can't - I'd rather
have 5.4 than wait for it. E.g., if we have somebody ready to commit for
certain timeframe to come up with it, then it makes sense to discuss it in
this context.Can't we just draw this arbitrary line in the sand, and say from now on,
controversial things are taken out and nothing new is added anymore?Everything which is not yet in trunk and is not required to round up the
release should go into the release after 5.4?For me it seems there is no progress because there is still to much
opportunity to improve things...
So, instead of allowing to nominate new features, it might be best to stick
to what we have now, and restrict ourselves to sort out the controversial
stuff.
I think that it would be nice to have a short timeframe before feature
freeze.
Tyrael
On Mon, May 9, 2011 at 9:50 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
another thing that I would love to see on the list: named parameters.
it was recently brought up, and I think that the original argument for
the rejection isn't true anymore:
http://www.php.net/~derick/meeting-notes.html#named-parameters
adding naming parameters would actually help to make clean and
maintainable code.I'm all for this idea, but the question is - can we have a good design &
implementation in next 2 months? If we can, great, if we can't - I'd rather
have 5.4 than wait for it. E.g., if we have somebody ready to commit for
certain timeframe to come up with it, then it makes sense to discuss it in
this context.
agree.
I think we could have a good one (if somebody actually start working on it),
so I think we should leave the door open for this and if it's got written
and approved before the code freeze then we will include it.
Tyrael
Hi!
I see the array shortcuts are on your todo discussion list there. We
probably shouldn't get into a full discussion on that since it will span
hundreds of messages. But if any of the folks who voted no last time
around have changed their minds, it would be good to know. And before
deciding, try using MongoDB from PHP for a couple of weeks. :)
I agree on both discussion point and MongoDB point :) I think for things
that were already discussed extensively it makes sense to have a vote in
case people changed their minds and discuss at length only if they have
something new to say - like proposing new approach to the problem -
which is this case probably won't happen.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi,
I'd love if you ever discuss these items for 5.4:
- ReflectionNamespace
Currently it's impossible to grab a docblock that documents an
Annotations, for example, or even access the namespace declaration.
It's also impossible to check which "use" is declared on the
namespace/file/class scope.
- Annotations
I already proposed a patch and none here discussed. You rather
preferred to shout "PHP doesn't need Annotations" instead of discuss
the patch that was proposed.
Actually, it was proposed twice, but it seems that you only looked at
first one (which I agree that was incompatible with PHP way of being).
Pierrick and I updated the patch to be as similar as possible with PHP
structure, but none here even looked at it. For those interested:
https://github.com/adoy/PHP-Annotations
- SplArray
We currently support SplInt, SplString, SplFloat, SplBool, etc. We
could support SplArray which would perfectly enhance implementations
that need to keep track of array state. Currently PHP provides 0
support on this area, and it would be nice if it provides a helpful
API to it. One good example to look at is:
https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Collections/Collection.php
- Comparable
Since operators overloading on PHP is hard to be implemented natively,
we could easily support it through OO. This idea can be extensively
discussed, but someone already proposed a patch previously any none
discussed it.
PS: I think that internals mailing list should be revised with all
proposed ideas and wrap them on a better plan.
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.
Regards,
Hi!
I see the array shortcuts are on your todo discussion list there. We
probably shouldn't get into a full discussion on that since it will span
hundreds of messages. But if any of the folks who voted no last time
around have changed their minds, it would be good to know. And before
deciding, try using MongoDB from PHP for a couple of weeks. :)I agree on both discussion point and MongoDB point :) I think for things
that were already discussed extensively it makes sense to have a vote in
case people changed their minds and discuss at length only if they have
something new to say - like proposing new approach to the problem - which is
this case probably won't happen.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
Martin Scotta
On Mon, May 9, 2011 at 11:44 AM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
Hi,
I'd love if you ever discuss these items for 5.4:
- ReflectionNamespace
Currently it's impossible to grab a docblock that documents an
Annotations, for example, or even access the namespace declaration.
It's also impossible to check which "use" is declared on the
namespace/file/class scope.
- Annotations
I already proposed a patch and none here discussed. You rather
preferred to shout "PHP doesn't need Annotations" instead of discuss
the patch that was proposed.
Actually, it was proposed twice, but it seems that you only looked at
first one (which I agree that was incompatible with PHP way of being).
Pierrick and I updated the patch to be as similar as possible with PHP
structure, but none here even looked at it. For those interested:
https://github.com/adoy/PHP-Annotations
- SplArray
We currently support SplInt, SplString, SplFloat, SplBool, etc. We
could support SplArray which would perfectly enhance implementations
that need to keep track of array state. Currently PHP provides 0
support on this area, and it would be nice if it provides a helpful
API to it. One good example to look at is:https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Collections/Collection.php
- Comparable
Since operators overloading on PHP is hard to be implemented natively,
we could easily support it through OO. This idea can be extensively
discussed, but someone already proposed a patch previously any none
discussed it.PS: I think that internals mailing list should be revised with all
proposed ideas and wrap them on a better plan.
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.
Totally agree.
a user.
Regards,
On Mon, May 9, 2011 at 5:38 AM, Stas Malyshev smalyshev@sugarcrm.com
wrote:Hi!
I see the array shortcuts are on your todo discussion list there. We
probably shouldn't get into a full discussion on that since it will span
hundreds of messages. But if any of the folks who voted no last time
around have changed their minds, it would be good to know. And before
deciding, try using MongoDB from PHP for a couple of weeks. :)I agree on both discussion point and MongoDB point :) I think for things
that were already discussed extensively it makes sense to have a vote in
case people changed their minds and discuss at length only if they have
something new to say - like proposing new approach to the problem - which
is
this case probably won't happen.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
- Annotations
I already proposed a patch and none here discussed. You rather
preferred to shout "PHP doesn't need Annotations" instead of discuss
the patch that was proposed.
If someone doesn't agree that annotations belong in PHP why do the
details of the patch matter?
PS: I think that internals mailing list should be revised with all
proposed ideas and wrap them on a better plan.
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.
That's simply not true. But just because one group of users feel
strongly about something doesn't mean it should go in. There has to be
some level of curation or we end up with every feature under the sun
resulting in a huge mess.
-Rasmus
regarding the annotations stuff: it seems the php community (in
general) really wants annotations. lots of important and widely used
frameworks use them (meaning that not only the plain php users have a
use for this feature, but also the users of the respective frameworks,
increasing the overall user number interested). i.e: doctrine,
symfony2, ding, phpunit, etc, etc. we cant just ignore this fact.
also, this means that there are tons of custom annotations
implementations (almost one per framework that has a use for them),
and we end up duplicating code and slowing the overall performance
for applications.
my question is: is php a language made for the php developers that
mantain the language or for the community that uses them and
contributes to it everyday?
just a thought
- Annotations
I already proposed a patch and none here discussed. You rather
preferred to shout "PHP doesn't need Annotations" instead of discuss
the patch that was proposed.If someone doesn't agree that annotations belong in PHP why do the details
of the patch matter?PS: I think that internals mailing list should be revised with all
proposed ideas and wrap them on a better plan.
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.That's simply not true. But just because one group of users feel strongly
about something doesn't mean it should go in. There has to be some level of
curation or we end up with every feature under the sun resulting in a huge
mess.-Rasmus
--
--
--
// I don't sleep. I coffee.
"Make everything as simple as possible, but not simpler." -- Albert Einstein
"The class object inherits from Chuck Norris."
"Chuck Norris can divide by zero and can unit test an entire
application with a single assert."
"There’s a lot of work happening behind the scenes, courtesy of the
Spring AOP framework"
"Why do I have this nagging hunch that you have no idea what you're doing?"
"Any society that would give up a little liberty to gain a little
security will deserve neither and lose both" - Benjamin Franklin
regarding the annotations stuff: it seems the php community (in
general) really wants annotations. lots of important and widely used
frameworks use them (meaning that not only the plain php users have a
use for this feature, but also the users of the respective frameworks,
increasing the overall user number interested). i.e: doctrine,
symfony2, ding, phpunit, etc, etc. we cant just ignore this fact.also, this means that there are tons of custom annotations
implementations (almost one per framework that has a use for them),
and we end up duplicating code and slowing the overall performance
for applications.my question is: is php a language made for the php developers that
mantain the language or for the community that uses them and
contributes to it everyday?
I don't know if annotations are needed in PHP 5.4.
There are a few libraries, out there, that can help developers, as you
said, from now.
Doctrine's one it's really powerful, and you can clone the repo from
github and easily start using the annotation library.
So my point is to say that, although we need a unified way to manage
annotations ( for the reasons Marcelo just explained ), they don't
need to be a focus point for PHP 5.4.
just a thought
- Annotations
I already proposed a patch and none here discussed. You rather
preferred to shout "PHP doesn't need Annotations" instead of discuss
the patch that was proposed.If someone doesn't agree that annotations belong in PHP why do the details
of the patch matter?PS: I think that internals mailing list should be revised with all
proposed ideas and wrap them on a better plan.
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.That's simply not true. But just because one group of users feel strongly
about something doesn't mean it should go in. There has to be some level of
curation or we end up with every feature under the sun resulting in a huge
mess.-Rasmus
--
--
--
// I don't sleep. I coffee.
"Make everything as simple as possible, but not simpler." -- Albert Einstein
"The class object inherits from Chuck Norris."
"Chuck Norris can divide by zero and can unit test an entire
application with a single assert."
"There’s a lot of work happening behind the scenes, courtesy of the
Spring AOP framework"
"Why do I have this nagging hunch that you have no idea what you're doing?"
"Any society that would give up a little liberty to gain a little
security will deserve neither and lose both" - Benjamin Franklin--
--
Nadalin Alessandro
www.odino.org
www.twitter.com/odino
Hi!
my question is: is php a language made for the php developers that
mantain the language or for the community that uses them and
contributes to it everyday?
Please stop trying to manipulate developers by suggesting if they don't
do exactly what you want they hate (or don't care for) all users. This
is obviously not true and does not contribute to the discussion.
As for the merits of the question, the problem is not having annotations
in general but having consistent, easy, performant model and
implementation that makes sense together with the rest of PHP. So far
none that were offered were good enough to satisfy that requirement and
gather consensus. I think it's better to wait and revisit it in the
future than to rush a half-baked concept now. Which means unless
somebody makes really strong proposal right now that people would
instantly like - it's not 5.4. It doesn't mean "never" either - it can
always be done in the next version. If there's something new to say on
the topic - great, let's see it.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
mm i don't remember saying anything like that :) i dont want to start
an argument here, but maybe you'd like to take things less personal
and re-read my post.
anyway, i think it's time to stop just saying "no", and really
collaborate with what the community is suggesting (and already
propsed) in order to bring this into php (5.4 or whatever).
Hi!
my question is: is php a language made for the php developers that
mantain the language or for the community that uses them and
contributes to it everyday?Please stop trying to manipulate developers by suggesting if they don't do
exactly what you want they hate (or don't care for) all users. This is
obviously not true and does not contribute to the discussion.As for the merits of the question, the problem is not having annotations in
general but having consistent, easy, performant model and implementation
that makes sense together with the rest of PHP. So far none that were
offered were good enough to satisfy that requirement and gather consensus. I
think it's better to wait and revisit it in the future than to rush a
half-baked concept now. Which means unless somebody makes really strong
proposal right now that people would instantly like - it's not 5.4. It
doesn't mean "never" either - it can always be done in the next version. If
there's something new to say on the topic - great, let's see it.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
--
// I don't sleep. I coffee.
"Make everything as simple as possible, but not simpler." -- Albert Einstein
"The class object inherits from Chuck Norris."
"Chuck Norris can divide by zero and can unit test an entire
application with a single assert."
"There’s a lot of work happening behind the scenes, courtesy of the
Spring AOP framework"
"Why do I have this nagging hunch that you have no idea what you're doing?"
"Any society that would give up a little liberty to gain a little
security will deserve neither and lose both" - Benjamin Franklin
mm i don't remember saying anything like that :) i dont want to start
an argument here, but maybe you'd like to take things less personal
and re-read my post.anyway, i think it's time to stop just saying "no", and really
collaborate with what the community is suggesting (and already
propsed) in order to bring this into php (5.4 or whatever).
Read what Richard just wrote please:
That's what Open Source is all
about. If you don't like the feature, or it is missing one, DO
something about it. Saying that the developers are "not interested"
isn't really doing anything.
You really can't expect volunteers to simply down tools from family,
life, paid work to jump through hoops, attempting to make sense of
every user's request. No matter how loud they shout.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
-----Original Message-----
From: Marcelo Gornstein [mailto:marcelog@gmail.com]
Sent: Monday, May 09, 2011 10:20 AM
To: Stas Malyshev
Cc: guilhermeblanco@gmail.com; PHP Internals
Subject: Re: [PHP-DEV] annotations againmm i don't remember saying anything like that :) i dont want to start an
argument here, but maybe you'd like to take things less personal and re-read
my post.anyway, i think it's time to stop just saying "no", and really collaborate with
what the community is suggesting (and already
propsed) in order to bring this into php (5.4 or whatever).
I absolutely agree we should be getting input from the various communities whether that's ZF, Symphony, Drupal, etc.. I do feel we get quite a bit of if it's not enough it should keep coming with very clear proposals. It'd also help if the frameworks would collaborate on such proposals. I know our ZF team has collaborated with other framework teams on a variety of fronts.
I do think this group does take clear proposals seriously but it's also important to remember that there has to be a strong bias to avoid feature creep and really focus on what's critical and not nice-to-have.
There are proposals that come up time and time again like operator overloading which just makes me cringe...
Andi
Hi all,
It's funny how far a simple discussion can reach.
I'm not advocating that an specific feature should go in or if not,
stimulate hate on developers.
Quoting what Richard and Derick posted, it's open source.
Any help from any front is very welcome. All I want is a place where
users (the entire php userland) can see what was discussed and the
results of it.
IIRC, open source is about community driven development. I don't see a
single thread message that pointed to a mature discussion about
feature A or B. All I saw was personal feelings about the inclusion of
feature A.
I'm a really pro supporter of Annotations in PHP, I also worked on an
Annotations patch for you. The first time I got a mature feedback to
turn the patch more PHP compatible, I agreed with php dev and worked
on changes to it. As soon as I published the patch updated with more
ideas and stable code, all I got was "Oh, come'on, this thread
again!".
None ever discussed this and you're (IMHO) saying no without even
looking at the patch. I can certain say that you don't even looked at
it because Richard (on the other thread) said that I could perfectly
have helped you writing C code. If he have ever clicked on link I
pointed out, he could clearly see that it's C patch fully tested and
compatible with latest php trunk.
So, please stop saying "no" to every feature request that comes in and
start to discuss the actual impact of each feature.
It's not because the feature came from userland that it doesn't have
any structure/design behind. It took months of planning and
structuring how it could be. All I need is someone that is not rude
and give me some clear feedback about possible enhancements that could
be done to be merged into php source code.
Thanks.
-----Original Message-----
From: Marcelo Gornstein [mailto:marcelog@gmail.com]
Sent: Monday, May 09, 2011 10:20 AM
To: Stas Malyshev
Cc: guilhermeblanco@gmail.com; PHP Internals
Subject: Re: [PHP-DEV] annotations againmm i don't remember saying anything like that :) i dont want to start an
argument here, but maybe you'd like to take things less personal and re-read
my post.anyway, i think it's time to stop just saying "no", and really collaborate with
what the community is suggesting (and already
propsed) in order to bring this into php (5.4 or whatever).I absolutely agree we should be getting input from the various communities whether that's ZF, Symphony, Drupal, etc.. I do feel we get quite a bit of if it's not enough it should keep coming with very clear proposals. It'd also help if the frameworks would collaborate on such proposals. I know our ZF team has collaborated with other framework teams on a variety of fronts.
I do think this group does take clear proposals seriously but it's also important to remember that there has to be a strong bias to avoid feature creep and really focus on what's critical and not nice-to-have.
There are proposals that come up time and time again like operator overloading which just makes me cringe...Andi
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
guilhermeblanco@gmail.com wrote:
So, please stop saying "no" to every feature request that comes in and
start to discuss the actual impact of each feature.
I think that MY only problem with you 'adding annotations because it is missing'
is simply that I've already been doing it for years - just not calling it
'annotations' ... its 'documentation' and always has been ...
MANY things that have been proposed are pushed as 'missing', when those of us
with a different ecosystem have solved the problem in other ways long ago and do
not see that.
The real problem at present is that the whole ecosystem is now so disjointed
that PHP5.2 is the last version that is still fairly fully supported, but people
are pushing for 5.4 before 5.3 has been properly put to bed. We need to finish
of what is already added fully before pushing more new stuff in? That INCLUDES
in the ecosystem!
And we still have the hole that is unicode ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/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,
guilhermeblanco@gmail.com wrote:
So, please stop saying "no" to every feature request that comes in and
start to discuss the actual impact of each feature.I think that MY only problem with you 'adding annotations because it is
missing' is simply that I've already been doing it for years - just not
calling it 'annotations' ... its 'documentation' and always has been ...
It is really troubling to read that statement. Seems there are still some
that don't really have a clue of what annotations are, even when the RFC
clearly links to them. Annotations ARE NOT documentation; in the case of
PHP, documentation is being used as annotations because there is no language
implementation, which exists in other languages (Java, .NET) and they are
widely used. Also, some use annotations as documentation (e.g. store the
class version), but again, annotations ARE NOT documentation. Don't let the
"@" notation shared with docblock fool you.
Guilherme, I think its easy to assume that people already have some sense of
what annotations are, but perhaps the wiki entry could be more educational
about it?. The first time I read about annotations it was from this link:
http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html;
perhaps an intro like that could help to make the case for annotations
crystal clear?.
The real problem at present is that the whole ecosystem is now so
disjointed that PHP5.2 is the last version that is still fairly fully
supported, but people are pushing for 5.4 before 5.3 has been properly put
to bed. We need to finish of what is already added fully before pushing more
new stuff in? That INCLUDES in the ecosystem!And we still have the hole that is unicode ...
This is another thing that troubles me when I read this list. How does the
PHP core dev community sets priorities?, is there some sort of roadmap?, is
there a process to create this roadmap?, or is it just all a generalized
best intention to do things.
I'm aware that the more features the more has to be maintained, but, what I
see is that there is lot of potential for the core dev community to grow and
at its current state it doesn't seem to be able scale due to the lack of a
roadmap/process.
I'm not trying to be a douche here, just saying: I see lots of criticism
towards everything and very few agreements.
Best regards,
David Vega
dukeofgaming wrote:
So, please stop saying "no" to every feature request that comes in and start to discuss the actual impact of each feature. I think that MY only problem with you 'adding annotations because it is missing' is simply that I've already been doing it for years - just not calling it 'annotations' ... its 'documentation' and always has been ...It is really troubling to read that statement. Seems there are still
some that don't really have a clue of what annotations are, even when
the RFC clearly links to them. Annotations ARE NOT documentation; in the
case of PHP, documentation is being used as annotations because there is
no language implementation, which exists in other languages (Java, .NET)
and they are widely used. Also, some use annotations as documentation
(e.g. store the class version), but again, annotations ARE NOT
documentation. Don't let the "@" notation shared with docblock fool you.Guilherme, I think its easy to assume that people already have some
sense of what annotations are, but perhaps the wiki entry could be more
educational about it?. The first time I read about annotations it was
from this link:
http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html;
perhaps an intro like that could help to make the case for annotations
crystal clear?.
But that aligns perfectly with my interpretation of 'annotations' - compiler
time commands and control - but we do not compile - we run the files raw.
It even say ...
Documentation
Many annotations replace what would otherwise have been comments in code.
And I can't see why the @interface complexity can't simply be replaced with the
existing docblock header which already has the same data contained. However that
is only part of the picture and passing information on parameters is what I am
seeing as the main use of annotation? ( this is probably going to wrap )
/**
* registerPackageUpgrade
*
* @param array $pParams Hash of information about upgrade
* @param string $pParams[package] Name of package that is upgrading
* @param string $pParams[version] Version of this upgrade
* @param string $pParams[description] Description of what the upgrade does
* @param string $pParams[post_upgrade] Textual note of stuff that needs to be observed after the upgrade
* @param array $pUpgradeHash Hash of update rules. See existing upgrades on how this works.
* @access public
* @return void
*/
function registerPackageUpgrade( $pParams, $pUpgradeHash = array() ) {
No doubt this could be automatically processed to to provide a java like view of
the same information, but what am I missing here? The data is already contained
in the code ... existing tools handle and display it ... but it is still easily
edited and read by any existing user?
Of cause doxygen requires a slightly different dialect to phpdoc, and THAT is
something that it would be worth investigating, but that is a different problem.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/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
This is another thing that troubles me when I read this list. How does the
PHP core dev community sets priorities?, is there some sort of roadmap?, is
there a process to create this roadmap?, or is it just all a generalized
best intention to do things.I'm aware that the more features the more has to be maintained, but, what I
see is that there is lot of potential for the core dev community to grow and
at its current state it doesn't seem to be able scale due to the lack of a
roadmap/process.I'm not trying to be a douche here, just saying: I see lots of criticism
towards everything and very few agreements.
The roadmap is in the form of a feature list which you can find at wiki.php.net/etc
There is never going to be complete agreement on any feature, but once there is enough agreement from the main stakeholders in a certain feature and the implementation looks feasible both from a technical perspective and from actually having someone willing to do the work, it gets assigned to a release.
In the case of annotations there were some serious stakeholders, like Matthew, Sebastian and others who really do understand what annotations are and why they are needed, but they did not agree with the proposed approach. That's why we have the RFCs and that's why these discussions flare up around release time. It triggers people to take a really serious look at a feature to see how it would work for them.
And yes there is a lot of noise. You will see quite a few uninformed opinions, and a few informed ones. We have always kept things completely open for anyone to have their say. This openness gives people access, but it also often gives people the sense that there is complete chaos. We are not .Net.
-Rasmus
The roadmap is in the form of a feature list which you can find at
http://wiki.php.net/etcwiki.php.net/etc
There is never going to be complete agreement on any feature, but once
there is enough agreement from the main stakeholders in a certain feature
and the implementation looks feasible both from a technical perspective and
from actually having someone willing to do the work, it gets assigned to a
release.
The link doesn't work, but I'm assuming it is this one?:
https://wiki.php.net/todo
In the case of annotations there were some serious stakeholders, like
Matthew, Sebastian and others who really do understand what annotations are
and why they are needed, but they did not agree with the proposed approach.
That's why we have the RFCs and that's why these discussions flare up around
release time. It triggers people to take a really serious look at a feature
to see how it would work for them.
In other words, the ideal situation to move this particular case forward is
to have more stakeholders join the discussion, right?. An issue that I see
here is that it is not that easy to join in the discussion because:
a) They would need to be already in the list to have an easy way to access
all the messages
b) The "thread" is too disperse to follow in
http://news.php.net/php.internals/
c) The public mirror of the newsgroup is faulty, see
http://news.php.net/php.internals/52242 for example
command too long: XPATH 4DC826B1.4090806@lerdorf.com <
4DC82A36.8090604@lerdorf.com> 4DC83401.2090202@sugarcrm.com<
4DC8D122.3050507@lsces.co.uk> 4DC8F125.2010503@toolpark.com <
4DC8FB1A.7040206@lerdorf.com>
My suggestion for this —and it would be a rather disruptive one, I know— is
to move the lists to Google Groups, or at least create one or two as an
experiment, say: php-userland and php-dev.
BTW, Guilherme is an important stakeholder too, he has participated in
Doctrine2 annotation-related work:
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/Driver/AnnotationDriver.php
And yes there is a lot of noise. You will see quite a few uninformed
opinions, and a few informed ones. We have always kept things completely
open for anyone to have their say. This openness gives people access, but it
also often gives people the sense that there is complete chaos. We are not
.Net.
That I understand, respect and applaud. Still, I think a better process
would provide more transparency (openness !== transparency), which is an
issue I've seen others complain about. This way, people willing to implement
their own feature might understand easier that if they help out with
existing actionable PHP problems, the community could shift more easily
their attention to their proposals.
The way I see it, PHP has moved by inertia all these years, and it has
worked, but I think there are measures that could be taken to lead the
discussions towards a more productive path. For example, is there anyone at
all that does some kind of moderation?, and I don't mean the coercive type,
but the "hey guys, this seems off-topic, can you start this discussion on
another email thread?" type of moderation.
Best regards,
David Vega
In other words, the ideal situation to move this particular case forward is
to have more stakeholders join the discussion, right?. An issue that I see
here is that it is not that easy to join in the discussion because:a) They would need to be already in the list to have an easy way to access
all the messages
NNTP exists and nntp://news.php.net does a good job in providing the
messages in a way that can be consumed by lots of different clients, web
based as well as "fat" clients.
b) The "thread" is too disperse to follow in
http://news.php.net/php.internals/
c) The public mirror of the newsgroup is faulty, see
http://news.php.net/php.internals/52242 for examplecommand too long: XPATH 4DC826B1.4090806@lerdorf.com <
4DC82A36.8090604@lerdorf.com> 4DC83401.2090202@sugarcrm.com<
4DC8D122.3050507@lsces.co.uk> 4DC8F125.2010503@toolpark.com <
4DC8FB1A.7040206@lerdorf.com>
We welcome patches for infrastructure, too :-)
johannes
dukeofgaming wrote:
c) The public mirror of the newsgroup is faulty, see
http://news.php.net/php.internals/52242 for example/command too long: XPATH <4DC826B1.4090806@lerdorf.com <mailto:4DC826B1.4090806@lerdorf.com>> <4DC82A36.8090604@lerdorf.com <mailto:4DC82A36.8090604@lerdorf.com>> <4DC83401.2090202@sugarcrm.com <mailto:4DC83401.2090202@sugarcrm.com>><4DC8D122.3050507@lsces.co.uk <mailto:4DC8D122.3050507@lsces.co.uk>> <4DC8F125.2010503@toolpark.com <mailto:4DC8F125.2010503@toolpark.com>> <4DC8FB1A.7040206@lerdorf.com <mailto:4DC8FB1A.7040206@lerdorf.com>>/
The 'fix' for this one is for the list to stop requiring the use of 'reply all'
and simply reply to just internals - But that is another religious war :)
I've got in the habit of killing all the extra reply addresses myself!
As for google ... don't expect people to follow you ... where I HAVE to reply to
a google list it is short and sweet ... There again perhaps that is how the list
culls 'trolls' like me ?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/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
dukeofgaming wrote:
c) The public mirror of the newsgroup is faulty, see
http://news.php.net/php.internals/52242 for example/command too long: XPATH <4DC826B1.4090806@lerdorf.com <mailto:4DC826B1.4090806@lerdorf.com>> <4DC82A36.8090604@lerdorf.com <mailto:4DC82A36.8090604@lerdorf.com>> <4DC83401.2090202@sugarcrm.com <mailto:4DC83401.2090202@sugarcrm.com>><4DC8D122.3050507@lsces.co.uk <mailto:4DC8D122.3050507@lsces.co.uk>> <4DC8F125.2010503@toolpark.com <mailto:4DC8F125.2010503@toolpark.com>> <4DC8FB1A.7040206@lerdorf.com <mailto:4DC8FB1A.7040206@lerdorf.com>>/The 'fix' for this one is for the list to stop requiring the use of 'reply all'
and simply reply to just internals - But that is another religious war :)
No, this is not the fix. These are the message ids of the mails in the
thread. The "external" "fix" would be not having such nested threads.
The proper fix is in http://svn.php.net/viewvc/web/php-news/ to limit
this.
I've got in the habit of killing all the extra reply addresses myself!
Which is bad, as it means that I don't get a reply to the sub-thread I'm
interested in (as i participated) to my inbox, but only in my internals
folder, where it easily disappears in a long thread.
johannes
Johannes Schlüter wrote:
I've got in the habit of killing all the extra reply addresses myself!
Which is bad, as it means that I don't get a reply to the sub-thread I'm
interested in (as i participated) to my inbox, but only in my internals
folder, where it easily disappears in a long thread.
I leave the folders on 'display unread' and only open them up if there is a need
to view the history. That way I can also see which list stuff is coming in from,
and don't need to later copy traffic to sub-folders? Again the ecosystem can be
fundamentally different for each of us so one person's + is another's -
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/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
It is really troubling to read that statement. Seems there are still some
that don't really have a clue of what annotations are, even when the RFC
clearly links to them. Annotations ARE NOT documentation; in the case of
PHP, documentation is being used as annotations because there is no language
implementation, which exists in other languages (Java, .NET) and they are
widely used. Also, some use annotations as documentation (e.g. store the
class version), but again, annotations ARE NOT documentation. Don't let the
"@" notation shared with docblock fool you.Guilherme, I think its easy to assume that people already have some sense of
what annotations are, but perhaps the wiki entry could be more educational
about it?. The first time I read about annotations it was from this link:
http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html;
perhaps an intro like that could help to make the case for annotations
crystal clear?.
I'm guessing experience and interpretation is everything here.
From reading the Oracle page, to me, it seems annotations ARE
documentation. It just depends upon who or what is reading them.
The first line of the page ...
"They have no direct effect on the operation of the code they annotate".
In other words, annotations are just like comments. At least in terms
of what I understand the "compiler" does and what the "runtime
processing" does.
The use of the @ isn't a fooling (according to Oracle) ... "The use of
the "@" symbol in both Javadoc comments and in annotations is not
coincidental—they are related conceptually.".
What I can't see from the link is WHY annotations can't just be
docblocks? Annotations and comments don't affect the code. Annotations
and comments would need to be parsed to read them.
I understand that caching of the annotation could be an issue. And
this leads to a gap in my knowledge/understanding. Why does this
script need to know anything about its annotations? Especially as
"They have no direct effect on the operation of the code they
annotate". It would seem wasteful to process dead data for no purpose
in this script. It only seems useful for some sort of external
process reading the annotation/comment (say a documentor or a tool to
build code for runtime operation). In those cases, these are one offs
(ish), so caching would not seem to serve any real benefit here.
Whilst I think the syntax of the annotation may be worth discussing,
the annotation can surely only exist in a comment, at least with
regard to PHP.
And I'm guessing that the primary use of annotations within PHP would
be in runtime processing, so is this really about the parsing of
docblocks.
I think using PHP code in a docblock (with the appropriate tag ...
@annotation maybe) would cover the requirements. Possibly. Due to
phpdocumentor not being updated to handle namespaces yet, annotations
are also not going to work correctly there.
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
Am 11.05.2011 13:31, schrieb Richard Quadling:
It is really troubling to read that statement. Seems there are still some
that don't really have a clue of what annotations are, even when the RFC
clearly links to them. Annotations ARE NOT documentation; in the case of
PHP, documentation is being used as annotations because there is no language
implementation, which exists in other languages (Java, .NET) and they are
widely used. Also, some use annotations as documentation (e.g. store the
class version), but again, annotations ARE NOT documentation. Don't let the
"@" notation shared with docblock fool you.Guilherme, I think its easy to assume that people already have some sense of
what annotations are, but perhaps the wiki entry could be more educational
about it?. The first time I read about annotations it was from this link:
http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html;
perhaps an intro like that could help to make the case for annotations
crystal clear?.I'm guessing experience and interpretation is everything here.
From reading the Oracle page, to me, it seems annotations ARE
documentation. It just depends upon who or what is reading them.The first line of the page ...
"They have no direct effect on the operation of the code they annotate".
In other words, annotations are just like comments. At least in terms
of what I understand the "compiler" does and what the "runtime
processing" does.
They have no direct affect of the operation of the code they annotate,
but they have affect of the code which runs the annotated code. So
annotations are no comments.
The use of the @ isn't a fooling (according to Oracle) ... "The use of
the "@" symbol in both Javadoc comments and in annotations is not
coincidental—they are related conceptually.".
I think the usage of the @ is historical. Because Java annotations in
the first implementation were DocBlock annotations parsed by XDocklet.
Starting with version 5 of the Java specification, they implemented
Annotations as part of the language.
http://www.devx.com/Java/Article/27235
What I can't see from the link is WHY annotations can't just be
docblocks? Annotations and comments don't affect the code. Annotations
and comments would need to be parsed to read them.I understand that caching of the annotation could be an issue. And
this leads to a gap in my knowledge/understanding. Why does this
script need to know anything about its annotations? Especially as
"They have no direct effect on the operation of the code they
annotate". It would seem wasteful to process dead data for no purpose
in this script. It only seems useful for some sort of external
process reading the annotation/comment (say a documentor or a tool to
build code for runtime operation). In those cases, these are one offs
(ish), so caching would not seem to serve any real benefit here.Whilst I think the syntax of the annotation may be worth discussing,
the annotation can surely only exist in a comment, at least with
regard to PHP.And I'm guessing that the primary use of annotations within PHP would
be in runtime processing, so is this really about the parsing of
docblocks.I think using PHP code in a docblock (with the appropriate tag ...
@annotation maybe) would cover the requirements. Possibly. Due to
phpdocumentor not being updated to handle namespaces yet, annotations
are also not going to work correctly there.Richard.
Why not learning from Java and implement annotations in the way
Guilherme proposed it? I think they had good reasons for the new
implementation. Maybe someone has a link which points to such discussion.
Best regards,
Christian
Why not learning from Java and implement annotations in the way
Guilherme proposed it? I think they had good reasons for the new
implementation. Maybe someone has a link which points to such discussion.
I believe you are looking for something like this
http://www.jcp.org/en/jsr/detail?id=250 and possibly others like JSR
175 and 308
There are a few others (google: JSR annotations).
Regards,
Drak
guilhermeblanco@gmail.com wrote:
So, please stop saying "no" to every feature request that comes in
and start to discuss the actual impact of each feature.I think that MY only problem with you 'adding annotations because it
is missing' is simply that I've already been doing it for years -
just not calling it 'annotations' ... its 'documentation' and always
has been ...It is really troubling to read that statement. Seems there are still
some that don't really have a clue of what annotations are, even when
the RFC clearly links to them. Annotations ARE NOT documentation; in
the case of PHP, documentation is being used as annotations because
there is no language implementation, which exists in other languages
(Java, .NET) and they are widely used. Also, some use annotations as
documentation (e.g. store the class version), but again, annotations
ARE NOT documentation. Don't let the "@" notation shared with docblock
fool you.
That may be the case. However, annotations within docblocks have been
the de facto standard for going on a decade. Adding a new language
feature at this point means several things:
- Developers using annotations in docblocks now need to consider
migrating to "true" annotations, which in turn means...- BC break of their code with previous versions of PHP.
- In many cases, not only are code changes needed (moving annotations
out of docblocks), but also likely the code handling the annotations
will need to be updated -- which means at least one if not several
maintenance cycles. Expensive. - And don't forget the cases where docblock annotations were serving
multiple purposes. A good example: ZF server classes utilize the same
docblock annotations used by phpDocumentor (well, now DocBlox!) in
order to deliver method signatures to clients. Switching to
annotations would end up duplicating information in this use case.
The point that myself and others have been trying to make is that we may
agree with the need for annotations, but due to the long-standing
history of using annotations in docblocks, coupled with the desire to
reduce potential BC breaks and maintenance cycles, we'd prefer to see
an annotation parser for docblocks vs a new language syntax.
Guilherme, I think its easy to assume that people already have some
sense of what annotations are, but perhaps the wiki entry could be
more educational about it?. The first time I read about annotations it
was from this link:
http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html;
perhaps an intro like that could help to make the case for annotations
crystal clear?.The real problem at present is that the whole ecosystem is now so
disjointed that PHP5.2 is the last version that is still fairly fully
supported, but people are pushing for 5.4 before 5.3 has been properly put
to bed. We need to finish of what is already added fully before pushing more
new stuff in? That INCLUDES in the ecosystem!And we still have the hole that is unicode ...
This is another thing that troubles me when I read this list. How does the
PHP core dev community sets priorities?, is there some sort of roadmap?, is
there a process to create this roadmap?, or is it just all a generalized
best intention to do things.I'm aware that the more features the more has to be maintained, but, what I
see is that there is lot of potential for the core dev community to grow and
at its current state it doesn't seem to be able scale due to the lack of a
roadmap/process.I'm not trying to be a douche here, just saying: I see lots of criticism
towards everything and very few agreements.Best regards,
David Vega
--0016e6d260d294be9504a2fa7db4--
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
regarding the annotations stuff: it seems the php community (in
general) really wants annotations. lots of important and widely used
frameworks use them (meaning that not only the plain php users have a
use for this feature, but also the users of the respective frameworks,
increasing the overall user number interested). i.e: doctrine,
symfony2, ding, phpunit, etc, etc. we cant just ignore this fact.
There are annotations, and annotations. Some folks are perfectly fine
with ad-hoc annotations support possible by parsing docblocks (Sebastian
B. has mentioned as much in relation to PHPUnit). Others are wanting
what is essentially a new, parsable, syntax on top of PHP. Others are
interested in this latter, but feel that a userland parser that uses
code generation to produce executable PHP code is sufficient.
The point is, there's still debate about whether the feature as proposed
is needed, and, if so, the full scope of features required to support
it, and what implications those have for the language.
also, this means that there are tons of custom annotations
implementations (almost one per framework that has a use for them),
and we end up duplicating code and slowing the overall performance
for applications.my question is: is php a language made for the php developers that
mantain the language or for the community that uses them and
contributes to it everyday?just a thought
- Annotations
I already proposed a patch and none here discussed. You rather
preferred to shout "PHP doesn't need Annotations" instead of discuss
the patch that was proposed.If someone doesn't agree that annotations belong in PHP why do the details
of the patch matter?PS: I think that internals mailing list should be revised with all
proposed ideas and wrap them on a better plan.
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.That's simply not true. But just because one group of users feel strongly
about something doesn't mean it should go in. There has to be some level of
curation or we end up with every feature under the sun resulting in a huge
mess.-Rasmus
--
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Am 09.05.2011 18:55, schrieb Marcelo Gornstein:
regarding the annotations stuff: it seems the php community (in
general) really wants annotations. lots of important and widely used
frameworks use them (meaning that not only the plain php users have a
use for this feature, but also the users of the respective frameworks,
increasing the overall user number interested). i.e: doctrine,
symfony2, ding, phpunit, etc, etc. we cant just ignore this fact.
I see no problem with the way that PHPUnit handles its annotations at
the moment. I do, however, see problems with a migration of PHPUnit to
an annotation system provided by PHP: whatever its syntax, if I wanted
to use it in PHPUnit that means that existing tests will have to be
changed.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
On Tue, May 10, 2011 at 11:35 AM, Sebastian Bergmann sebastian@php.netwrote:
Am 09.05.2011 18:55, schrieb Marcelo Gornstein:
regarding the annotations stuff: it seems the php community (in
general) really wants annotations. lots of important and widely used
frameworks use them (meaning that not only the plain php users have a
use for this feature, but also the users of the respective frameworks,
increasing the overall user number interested). i.e: doctrine,
symfony2, ding, phpunit, etc, etc. we cant just ignore this fact.I see no problem with the way that PHPUnit handles its annotations at
the moment. I do, however, see problems with a migration of PHPUnit to
an annotation system provided by PHP: whatever its syntax, if I wanted
to use it in PHPUnit that means that existing tests will have to be
changed.
why would you migrate if you are fine with your current setup?
Tyrael
Hi Rasmus,
- Annotations
I already proposed a patch and none here discussed. You rather
preferred to shout "PHP doesn't need Annotations" instead of discuss
the patch that was proposed.If someone doesn't agree that annotations belong in PHP why do the details
of the patch matter?
The actual concern is that someone didn't agree with that and (re-read
the thread to comment this), also confirmed that never used
Annotations and have a "very superficial knowledge" of the
possibilities, than to me it's more than clear to me that it's not a
valid opinion. If it is for you, then PHP has a problem.
PS: I think that internals mailing list should be revised with all
proposed ideas and wrap them on a better plan.
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.That's simply not true. But just because one group of users feel strongly
about something doesn't mean it should go in. There has to be some level of
curation or we end up with every feature under the sun resulting in a huge
mess.
Are you sure?
Please take a look at every topic defined on wiki page. Is there ANY
topic to be discussed that came from userland?
If you say yes, please point me to the thread. What I clearly see
there is that every feature defined there came from users with php-src
karma.
Now I re-ask you, are you really sure it's only a small group that
want something or do you now confirm that only php-src users have
relevance on features request?
-Rasmus
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
That's simply not true. But just because one group of users feel strongly
about something doesn't mean it should go in. There has to be some level
of
curation or we end up with every feature under the sun resulting in a
huge
mess.Are you sure?
Please take a look at every topic defined on wiki page. Is there ANY
topic to be discussed that came from userland?
If you say yes, please point me to the thread. What I clearly see
there is that every feature defined there came from users with php-src
karma.
there is at least one, mine
but I also think that the core devs and the php userland/community is too
far away, we would need more people from the userland to contribute to the
development of the php language.
http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6
http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6“Because
it’s nearly impossible toparticipate on Internals if yourpoo-throwing arm
isn’t strong.” — @coates
“Those with talent, competence, energy,and good ideas over a period of time
- and who outlast the rest - tend to be the main drivers behind
PHPdevelopment.” — @a
Tyrael
That's simply not true. But just because one group of users feel
strongly
about something doesn't mean it should go in. There has to be some
level
of
curation or we end up with every feature under the sun resulting in a
huge
mess.Are you sure?
Please take a look at every topic defined on wiki page. Is there ANY
topic to be discussed that came from userland?
If you say yes, please point me to the thread. What I clearly see
there is that every feature defined there came from users with php-src
karma.there is at least one, mine
but I also think that the core devs and the php userland/community is too
far away, we would need more people from the userland to contribute to the
development of the php language.http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6
<
http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6“Because
it’s nearly impossible toparticipate on Internals if yourpoo-throwing arm
isn’t strong.” — @coates
“Those with talent, competence, energy,and good ideas over a period of time
- and who outlast the rest - tend to be the main drivers behind
PHPdevelopment.” — @aTyrael
Hi,
After having some experience participating in other open-source communities,
specially Joomla (but also Mootools, Doctrine and Symfony), my first
impression when subscribing and reading this list was: "wow, its hostile",
and I automatically refrained from wanting to participate and chose just to
observe for the meantime.
I know every community is different, but, even if a single person states
something that might look like a problem it is an indicator that you might
have it.
I think the PHP community could benefit from a process like Python's PEP
Workflow: http://www.python.org/dev/peps/pep-0001/#pep-work-flow.
Personal attacks achieve nothing, and contributing to open-source is MORE
than contributing code, and even if you do contribute, it doesn't look like
it is even an automatic way to get the needed attention. I've seen Guilherme
post several times asking for feedback (i.e. building upon his work, not
just criticizing him) and I have never seen it. I don't think Guilherme
loves spending his afternoons advancing in a patch without the slightest
sense of community direction.
Being brutally honest, looks to me that this generalized attitude/culture
might actually be scaring willing devs away, and the community itself needs
some kind of direction. Here is a recommended watch:
O'Reilly MySQL CE 2010: Jono Bacon, "The Engines Of Community":
http://blip.tv/file/3495291
Best regards,
David
Hi:
Are you sure?
Please take a look at every topic defined on wiki page. Is there ANY
topic to be discussed that came from userland?
If you say yes, please point me to the thread. What I clearly see
there is that every feature defined there came from users with php-src
karma.
Now I re-ask you, are you really sure it's only a small group that
want something or do you now confirm that only php-src users have
relevance on features request?
Just for the sake of argument, a single counter-example can prove you wrong.
And that counter-example is traits.
I implemented the traits long before I got actual karma, and why do we have traits in trunk now?
Because I kept arguing that they are useful, and that I as a user want them.
Others liked the idea, and eventually I got the karma to push the code into the official repository.
First it was developed completely outside of PHP and without asking anyone from internals, just because I wanted it...
That is how open source works.
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
Am 09.05.2011 21:33, schrieb Stefan Marr:
That is how open source works.
Traits is a perfect example, indeed: you came to the list with a clear
specification of the feature as well as arguments for why you think the
feature is useful. Moreover, you provided tests that reflected the
specification and a patch that implemented the specification and
satisfied the tests.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
On Tue, May 10, 2011 at 11:40 AM, Sebastian Bergmann sebastian@php.netwrote:
Am 09.05.2011 21:33, schrieb Stefan Marr:
That is how open source works.
Traits is a perfect example, indeed: you came to the list with a clear
specification of the feature as well as arguments for why you think the
feature is useful. Moreover, you provided tests that reflected the
specification and a patch that implemented the specification and
satisfied the tests.
how is it different from the annotations proposed by Guilherme and Pierrick?
the only difference that the traits got accepted and the annotations not
(yet), but they were both announced ~ the same time, both were backed up
with rfc, implementation and tests.
http://marc.info/?l=php-internals&m=128274106801222&w=2
if you follow the topic, you will see that the same people brought up the
same arguments against adding traits than we can see about
annotations(comparing traits to include, annotations to docblocks,
performance problems, playing the bloated card, etc.), but they were
overwhelmed by the positive feedback and the buzz about what can be further
improved, etc.
it seems that annotations lacked the critical mass when it was proposed. :(
Tyrael
performance problems, playing the bloated card, etc.), but they were
overwhelmed by the positive feedback and the buzz about what can be further
improved, etc.
it seems that annotations lacked the critical mass when it was proposed. :(
From my perspective, getting Traits in was also a lot of hard work with respect to the community.
(Actually more then the technical details).
While there seemed to be quite some buzz in the general PHP world, internals was rather uninterested in the beginning.
The whole thing required a lot of, what I would characterize as, hand-holding.
Internals is not the most open community and needs not only good arguments, but persistence.
And, well, it also seem to require to get in touch with the right people...
And now the whole discussion about 5.4 goes again in a direction where it will probably be stalled in the end.
I am not to optimistic about an actual release date within 2011.
Best regards
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
The whole thing required a lot of, what I would characterize as,
hand-holding. Internals is not the most open community and needs not
only good arguments, but persistence. And, well, it also seem to
require to get in touch with the right people...And now the whole discussion about 5.4 goes again in a direction
where it will probably be stalled in the end. I am not to optimistic
about an actual release date within 2011.
Don't lose your head on it. If you look at the output buffering code
contained in trunk (which is to become 5.4), you may discover that it
has been written exactly 5 years ago.
Cheers,
Mike
The whole thing required a lot of, what I would characterize as,
hand-holding. Internals is not the most open community and needs not
only good arguments, but persistence. And, well, it also seem to
require to get in touch with the right people...And now the whole discussion about 5.4 goes again in a direction
where it will probably be stalled in the end. I am not to optimistic
about an actual release date within 2011.Don't lose your head on it. If you look at the output buffering code
contained in trunk (which is to become 5.4), you may discover that it
has been written exactly 5 years ago.
gasps
Well, maybe it's time to make some decisions and start to spin the wheels?
I's quite obvious that annotations are out for next release until they are a
docbook/phpDoc style. Personally I do not understand the concept fully, but
my vote will definetly go to the docbook/phpdoc variant. Adding a whole new
syntax is just crazy. PHP is a scripting language, not the Java/C# and
alike, it should stay simple. Period.
I hope KISS still is a PHP principle?
Sometimes i'm sorry I don't like to do C - it just scared me away in
college. Because people here sometimes just do strange things witch tend me
to beleve that they do not know the PHP - they know C and try to add things
they know from other languages so they don't have to learn the PHP way of
doing things. Till the typehint threads and annotation threads i liked the
core developer responces and the way php has been heading. Can we keep that
and stop discussing things that are 100% alien to php like strict type
hinting? in php? are you insane? same with annotations. wana do them? do
them simple. docbook/phpdoc annotations allready exist - work out a standart
and implement - clean, simple, fast and all ready exists within community.
It's a no brainer.
Same with features that have been worked on and forgotten. Revisit, finish
and people will like it - there are thing people ask and thouse aren't
annotations right now. Community wants typehints and a bunch of stuff from
that RFC page.
I hope a spark of reason and sanity will ignight and the procces will start
in a few days, or PHP will be seriously screwed in a few years and i will
have to make python my primary web development language and i don't wana do
that.
Arvids.
Martin Scotta
On Wed, May 11, 2011 at 2:18 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:
Well, maybe it's time to make some decisions and start to spin the wheels?
I's quite obvious that annotations are out for next release until they are
a
docbook/phpDoc style. Personally I do not understand the concept fully, but
my vote will definetly go to the docbook/phpdoc variant. Adding a whole new
syntax is just crazy. PHP is a scripting language, not the Java/C# and
alike, it should stay simple. Period.
I hope KISS still is a PHP principle?Sometimes i'm sorry I don't like to do C - it just scared me away in
college. Because people here sometimes just do strange things witch tend me
to beleve that they do not know the PHP - they know C and try to add things
they know from other languages so they don't have to learn the PHP way of
doing things. Till the typehint threads and annotation threads i liked the
core developer responces and the way php has been heading. Can we keep that
and stop discussing things that are 100% alien to php like strict type
hinting? in php? are you insane? same with annotations. wana do them? do
them simple. docbook/phpdoc annotations allready exist - work out a
standart
and implement - clean, simple, fast and all ready exists within community.
It's a no brainer.
Clean? Simple? fast? are you talking about PHP? :)
Now seriously I feel that trying to put things from other languages is
wrong, but that don't prevent us from learning from what other had learn
before.
For me, annotations belongs to Object Oriented programming, no matter where
they came from.
Probably this list is too C to speak about OO ?
Same with features that have been worked on and forgotten. Revisit, finish
and people will like it - there are thing people ask and thouse aren't
annotations right now. Community wants typehints and a bunch of stuff from
that RFC page.I hope a spark of reason and sanity will ignight and the procces will start
in a few days, or PHP will be seriously screwed in a few years and i will
have to make python my primary web development language and i don't wana do
that.Arvids.
--0016e657b06a1ac32a04a2e91661
Content-Type: text/plain; charset=UTF-8Am 09.05.2011 21:33, schrieb Stefan Marr:
That is how open source works.
Traits is a perfect example, indeed: you came to the list with a clear
specification of the feature as well as arguments for why you think the
feature is useful. Moreover, you provided tests that reflected the
specification and a patch that implemented the specification and
satisfied the tests.how is it different from the annotations proposed by Guilherme and Pierrick?
the only difference that the traits got accepted and the annotations not
(yet), but they were both announced ~ the same time, both were backed up
with rfc, implementation and tests.
http://marc.info/?l=php-internals&m=128274106801222&w=2
if you follow the topic, you will see that the same people brought up the
same arguments against adding traits than we can see about
annotations(comparing traits to include, annotations to docblocks,
performance problems, playing the bloated card, etc.), but they were
overwhelmed by the positive feedback and the buzz about what can be further
improved, etc.
it seems that annotations lacked the critical mass when it was proposed. :(
Traits, to me, was a very different proposal. Why? Because there was no
way to emulate the functionality within the language already.
With annotations, my main issue, which I voiced early (and others did as
well), is that we can already do much of what the RFC proposes by
parsing annotations in docblocks. In fact, adding the support
potentially creates more work for developers (more on that below).
I don't see a need for a new grammar and syntax; why don't we just
provide a standard for annotations within docblocks, and provide a
native parser for annotations that follow that format? This allows folks
who are already using docblock annotations a boost in speed, and only
gets invoked during reflection (since otherwise it's considered a
comment).
Guilherme often raises ZF's server classes as poster children for why
annotations support is needed. However, I'd like to note that I don't
feel this way at all. In fact, annotations support would create more
work for us. Why? Because now we'd need both our docblock comments (in
order to generate the API docs) AND annotations (to provide the server
hinting we provide, which currently is derived from PHPDoc annotations).
A native docblock annotation parser would much better suit our purposes.
So, basically, we're in a situation where there's no consensus on
whether the feature is needed or what the approach should be, and people
pointing fingers at eachother indicating the other party is not
listening or providing constructive feedback. I think that's reason
enough to pan the feature for 5.4.
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Matthew Weier O'Phinney wrote:
Guilherme often raises ZF's server classes as poster children for why
annotations support is needed. However, I'd like to note that I don't
feel this way at all. In fact, annotations support would create_more_
work for us. Why? Because now we'd need both our docblock comments (in
order to generate the API docs) AND annotations (to provide the server
hinting we provide, which currently is derived from PHPDoc annotations).
A native docblock annotation parser would much better suit our purposes.
Thank you Matthew. That was the part of the 'problem' I was not getting across
very well. The bulk of my existing code base has this documentation already, and
phpeclipse simply picks it up and runs with it ...
including type hinting ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/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
Matthew Weier O'Phinney wrote:
Thank you Matthew. That was the part of the 'problem' I was not getting
across very well. The bulk of my existing code base has this documentation
already, and phpeclipse simply picks it up and runs with it ...
including type hinting ...
If PHP releases new syntax of course the IDE vendors will release
support pronto for it.
Drak
Drak wrote:
Matthew Weier O'Phinney wrote:
Thank you Matthew. That was the part of the 'problem' I was not getting
across very well. The bulk of my existing code base has this documentation
already, and phpeclipse simply picks it up and runs with it ...
including type hinting ...
If PHP releases new syntax of course the IDE vendors will release
support pronto for it.
Which world do you live in? We have to find the time to DO all this extra work!
Or are you only using commercial product?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/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
Am 10.05.2011 17:57, schrieb Matthew Weier O'Phinney:
I think that's reason enough to pan the feature for 5.4.
Agreed.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
May-10-11 11:57 AM Matthew Weier O'Phinney wrote:
A native docblock annotation parser would much better suit our
purposes.
+1, FWIW.
So, basically, we're in a situation where there's no consensus on
whether the feature is needed or what the approach should be, and
people pointing fingers at eachother indicating the other party is
not listening or providing constructive feedback. I think that's
reason enough to pan the feature for 5.4.
Humbly, I agree.
Best Regards,
Mike Robinson
May-10-11 11:57 AM Matthew Weier O'Phinney wrote:
A native docblock annotation parser would much better suit our
purposes.+1, FWIW.
extending the Reflection::getDocComment to support retrieving the docblock
comment as an array of key => value pairs wouldn't be too hard to implement.
I find it funny that you, Sebastian and others who are supporting docblocks
over annotations didn't found the time to do it, but you always bring this
up.
Tyrael
--bcaec51a7af89cba6304a2f01d01
Content-Type: text/plain; charset=UTF-8May-10-11 11:57 AM Matthew Weier O'Phinney wrote:
A native docblock annotation parser would much better suit our
purposes.+1, FWIW.
extending the Reflection::getDocComment to support retrieving the docblock
comment as an array of key => value pairs wouldn't be too hard to implement.
I find it funny that you, Sebastian and others who are supporting docblocks
over annotations didn't found the time to do it, but you always bring this
up.
We have in ZF -- Zend_Reflection extends the Reflection API to provide
this sort of feature (though admittedly the annotation, or "tag" support
as we called it, could use a little more rigor in matching). I
personally am not comfortable enough in my C skills to attempt it in the
Zend Engine.
--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
I find it funny that you, Sebastian and others who are supporting docblocks
over annotations didn't found the time to do it, but you always bring this
up.
http://pecl.php.net/package/docblock exists. I never used it, but either
it is completely unknown or doesn't bring benefits over a userspace
implementation (typical trade-offs: A C implementation is harder to
maintain for developers and harder to install for users, while the PHP
implementation is slower)
johannes
Am 09.05.2011 21:33, schrieb Stefan Marr:
That is how open source works.
Traits is a perfect example, indeed: you came to the list with a clear
specification of the feature as well as arguments for why you think the
feature is useful. Moreover, you provided tests that reflected the
specification and a patch that implemented the specification and
satisfied the tests.
That is the way to meet with the least resistance for sure, however,
it's better to sound out the idea beforehand before you waste time on
something that might get stone-walled. But, even a lone well
thought-out specification may be picked apart by group scrutinisation.
Overall in OSS, the problem is if you don't sound out an idea first,
you might be wasting your time if it's stonewalled, but if you don't
immediately provide a specification and patch, you get resistance
because "it's yet another feature request" to an already overworked,
and over burdened core development team. Contrasting, if you propose
something that is generally liked by the core development team, you
may not even have to write a patch for it to materialise. Getting
something approved is therefore not so straightforward - you need some
luck and who's reading the list at the time...
Probably what is missing is some sort of crowd sourcing to really
gauge opinion on a wider basis. Something like this
http://ideas.joomla.org makes it very clear what is important to the
wider community or not.
Regards,
Drak
Hello Internals!
Here is a point of view from an active user land developer on PHP
development and feature requests and the politics going on in
internals.
Right now I think PHP has reached a milestone, where it is a need to
take a break from large feature developing, witch takes a lot of time
and effort, and do the cleanup stuff - bugs, accepted and unfinished
features, make enhancement on existing stuff and clean up the code.
New features should still come in, but the focus really should be to
make a cleanup. I have observed over 3-4 years now some good RFC's
that had been just forgotten, despite the fact that they were welcomed
and work has been done. For example:
The Tainted Variable RFC - https://wiki.php.net/rfc/taint - personally
I would prefer that feature right now over any new feature, because it
gives the ability to check for insecure variable handling and make
sure you don't miss something. A major security enhancement on the
language level (how the people can and will abuse it is not the issue
- people do SQL selects in loops - tainted variable abuse is just
negligent compared to that one) - isn't it worth the effort to finish
that and release?
The Lemon parser - https://wiki.php.net/rfc/lemon - I remember a lot
of discussions on that and work being done and people wanting to do
it. What happened?
Error handling RFC's - https://wiki.php.net/rfc/error-optimizations
and https://wiki.php.net/rfc/enhanced_error_handling - it's sitting
there for quite some time. Any thought on that? Because error handling
improvements will benifit all PHP developers - every single PHP
developer out there in the wild.
PHP Native Interface - https://wiki.php.net/rfc/php_native_interface -
sounds and looks like a good and important project.
And I even will not touch the topic of type hints and return type
hints. At least param type hinting should be dealt with and done
something about it, because right now it's at a half-completed state -
only arrays and objects are supported.
And probably the RFC wiki should be looked at and sorted out - there
are some things implemented and rejected, witch haven't been moved to
proper sections.
Said all that - I think annotations should be dropped for 5.4 for now
and the development and refining continued until it's properly
scrutinized, tested and ironed out. Right now to focus on delivering
stuff that's all ready done or near completed (performance
improvements for example) and look at the backlog and bugs.
Arvids.
On Tue, May 10, 2011 at 1:43 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:
Hello Internals!
Here is a point of view from an active user land developer on PHP
development and feature requests and the politics going on in
internals.Right now I think PHP has reached a milestone, where it is a need to
take a break from large feature developing, witch takes a lot of time
and effort, and do the cleanup stuff - bugs, accepted and unfinished
features, make enhancement on existing stuff and clean up the code.
New features should still come in, but the focus really should be to
make a cleanup. I have observed over 3-4 years now some good RFC's
that had been just forgotten, despite the fact that they were welcomed
and work has been done. For example:The Tainted Variable RFC - https://wiki.php.net/rfc/taint - personally
I would prefer that feature right now over any new feature, because it
gives the ability to check for insecure variable handling and make
sure you don't miss something. A major security enhancement on the
language level (how the people can and will abuse it is not the issue
- people do SQL selects in loops - tainted variable abuse is just
negligent compared to that one) - isn't it worth the effort to finish
that and release?
http://marc.info/?l=php-internals&m=129009775610865&w=2
http://marc.info/?l=php-internals&m=129009775610865&w=2
The Lemon parser - https://wiki.php.net/rfc/lemon - I remember a lot
of discussions on that and work being done and people wanting to do
it. What happened?
http://marc.info/?l=php-internals&m=128872242418092&w=2
and as a bonus:
http://marc.info/?l=php-internals&m=128864465522116&w=2
Error handling RFC's - https://wiki.php.net/rfc/error-optimizations
and https://wiki.php.net/rfc/enhanced_error_handling - it's sitting
there for quite some time. Any thought on that? Because error handling
improvements will benifit all PHP developers - every single PHP
developer out there in the wild.
PHP Native Interface - https://wiki.php.net/rfc/php_native_interface -
sounds and looks like a good and important project.
yeah, but AFAIK it wasn't finished, and by the comments I'm not entirely
sure that it's possible or viable at all.
http://marc.info/?l=php-internals&m=123901102014697&w=2
And I even will not touch the topic of type hints and return type
hints. At least param type hinting should be dealt with and done
something about it, because right now it's at a half-completed state -
only arrays and objects are supported.
that's a touchy subject.
And probably the RFC wiki should be looked at and sorted out - there
are some things implemented and rejected, witch haven't been moved to
proper sections.
+1
Said all that - I think annotations should be dropped for 5.4 for now
and the development and refining continued until it's properly
scrutinized, tested and ironed out. Right now to focus on delivering
stuff that's all ready done or near completed (performance
improvements for example) and look at the backlog and bugs.
"One of things I love most about working with Open Source Software like PHP
is the freedom. If I have an itch, I scratch it! If I want to work on new
features or document all the kinks and quirks of PHP, I can. We have the
freedom to work on exactly the things we care about and want to do."
so the problem is, that the userland is under-represented in the
development, because they usually not present on the mailing list and on
irc, where discussions and decisions happen, and they usually have different
priorities and expectations about the PHP language than the core devs.
to make things worse, they cannot write patches for the core, and the core
devs rarely work on something which they don't particularly need or like.
and I think that the only option where we can change that, is that us, the
php userland devs has to be more active on the mailing lists, irc, bug
tracking, writing RFCs etc.
ps:
"Right now I think PHP has reached a milestone, where it is a need to
take a break from large feature developing"
your suggestions also contains really large features.
I would add the unicode and LFS support for that list.
they are both long requested features, and nothing really happening to solve
those.
Tyrael
so the problem is, that the userland is under-represented in the
development, because they usually not present on the mailing list and
on
irc, where discussions and decisions happen, and they usually have
different
priorities and expectations about the PHP language than the core
devs.
to make things worse, they cannot write patches for the core, and the
core
devs rarely work on something which they don't particularly need or
like.and I think that the only option where we can change that, is that
us, the
php userland devs has to be more active on the mailing lists, irc,
bug
tracking, writing RFCs etc.
I'm a userland developer, reading the list since two years I think. And
I must say I'm totally frustrated about the developing process itself.
The actual proposal process is always the same:
- Someone proposes a new feature.
- As next there is a long discussion about the topic which ends up
with more dissent than consensus. - A long time nothing about the topic.
- Start new from first point.
And I think in the near feature there will be no changes with the old
structures.
Greetings
Christian
Hi,
<...>
so the problem is, that the userland is under-represented in the
development, because they usually not present on the mailing list and on
irc, where discussions and decisions happen, and they usually have different
priorities and expectations about the PHP language than the core devs.
to make things worse, they cannot write patches for the core, and the core
devs rarely work on something which they don't particularly need or like.and I think that the only option where we can change that, is that us, the
php userland devs has to be more active on the mailing lists, irc, bug
tracking, writing RFCs etc.
I have a feeling that even though PHP's users are happen to be
developers, they won't do these. Or they might do, but they'd
practically become core developers.
Open Source users want shiny web42.0 interfaces where they can 'upvote'
ideas. And if every year the topmost idea would get implemented, they
would be happy. (It's just how humans work, in my opinion.)
PHP users might file bugs. Might read RFCs when linked to. Occasionally
read the mailing list to figure out What's cooking in Internals. But
after seeing endless pages about "get a perfect idea, write a patch,
document it in an RFC, wait for SVN account, and maybe we'll look at it"
they aren't likely to jump in.
And even though some parts of the userbase is quite engaged (
https://github.com/symfony/symfony/pulls
https://github.com/symfony/symfony/graphs/traffic - selection bias and
whatnot ), there's still a very big barrier between writing a pull
request on the off chance that some might incorporate it versus raging
on internals for months.
So, it's just not going to happen.
Thus I don't find it surprising that framework/library developers are
the ones hanging around and not the CompSci freshmen that stumbled upon
a PHP tutorial.
Also, PHP being in fact very flexible and fast, and well documented,
there aren't a lot of userland problems that would scream for immediate
divine core developer intervention. So that's an other factor why
there's little to no interaction with developers.
And when there are problems, they're usually very complex (unicode) or
solving them would require virtually shifting the whole language
(multi-threading support, from more opcode caching to pre-compiled
"binaries", long running persistent PHP apps to reduce class loading and
other initialization penalty). It looks like for most uses of PHP other
languages would be better suited, except they suck more for various
reasons (Java - plain old and full of bloated frameworks; Scala - too
much awesome packed into it results in a steep learning curve; ASP.NET -
Windows only).
And I haven't mentioned Python, because it gets used, it's growing (and
I suspect a lot of people are 'converting' to it):
http://www.go-hero.net/jam/11/languages
--
Pas
ps:
"Right now I think PHP has reached a milestone, where it is a need to
take a break from large feature developing"
your suggestions also contains really large features.
I would add the unicode and LFS support for that list.
they are both long requested features, and nothing really happening to solve
those.Tyrael
2011/5/10 Ferenc Kovacs info@tyrael.hu:
The Tainted Variable RFC - https://wiki.php.net/rfc/taint - personally
I would prefer that feature right now over any new feature, because it
gives the ability to check for insecure variable handling and make
sure you don't miss something. A major security enhancement on the
language level (how the people can and will abuse it is not the issue
- people do SQL selects in loops - tainted variable abuse is just
negligent compared to that one) - isn't it worth the effort to finish
that and release?
Well, there is the impact, but seriously, do that many people will use
it in production? I certainly will not, but on the DEV and on my local
development machine it will be enabled period.
The Lemon parser - https://wiki.php.net/rfc/lemon - I remember a lot
of discussions on that and work being done and people wanting to do
it. What happened?http://marc.info/?l=php-internals&m=128872242418092&w=2
and as a bonus:
http://marc.info/?l=php-internals&m=128864465522116&w=2
The thing here is that there seems to be no movement at all. As I
remember, there just has to be work done to write the grammar parser
in Lemon in a such way, that it is fast enough and would have range
for improvements. Right now it seems that no one is even trying.
Error handling RFC's - https://wiki.php.net/rfc/error-optimizations
and https://wiki.php.net/rfc/enhanced_error_handling - it's sitting
there for quite some time. Any thought on that? Because error handling
improvements will benifit all PHP developers - every single PHP
developer out there in the wild.
Yep, bad suggestion from my side :)
PHP Native Interface - https://wiki.php.net/rfc/php_native_interface -
sounds and looks like a good and important project.yeah, but AFAIK it wasn't finished, and by the comments I'm not entirely
sure that it's possible or viable at all.
http://marc.info/?l=php-internals&m=123901102014697&w=2
It was more like an example of abandoned projects witch stay on RFC
page for long time and make an impression that it will be dealt with.
Just move it to "Not accepted/Abbandoned" category then.
And I even will not touch the topic of type hints and return type
hints. At least param type hinting should be dealt with and done
something about it, because right now it's at a half-completed state -
only arrays and objects are supported.that's a touchy subject.
Indeed it is. But at least the param type hinting should be finished,
cause it's all ready half there.
And probably the RFC wiki should be looked at and sorted out - there
are some things implemented and rejected, witch haven't been moved to
proper sections.+1
Said all that - I think annotations should be dropped for 5.4 for now
and the development and refining continued until it's properly
scrutinized, tested and ironed out. Right now to focus on delivering
stuff that's all ready done or near completed (performance
improvements for example) and look at the backlog and bugs."One of things I love most about working with Open Source Software like PHP
is the freedom. If I have an itch, I scratch it! If I want to work on new
features or document all the kinks and quirks of PHP, I can. We have the
freedom to work on exactly the things we care about and want to do."
so the problem is, that the userland is under-represented in the
development, because they usually not present on the mailing list and on
irc, where discussions and decisions happen, and they usually have different
priorities and expectations about the PHP language than the core devs.
to make things worse, they cannot write patches for the core, and the core
devs rarely work on something which they don't particularly need or like.
and I think that the only option where we can change that, is that us, the
php userland devs has to be more active on the mailing lists, irc, bug
tracking, writing RFCs etc.
Yes, it is the problem. And usually the userland developer voices are
just overflown by other people - core devs and people who invest in
developing their own stuff. Maybe core devs could somehow highlight
the things that userland developers are writing?
ps:
"Right now I think PHP has reached a milestone, where it is a need to
take a break from large feature developing"
your suggestions also contains really large features.
I would add the unicode and LFS support for that list.
they are both long requested features, and nothing really happening to solve
those.Tyrael
That was the intent of my e-mail in the first place - to show that
there is a ton of stuff that is in questionable state, half done or
most of the problems solved and it just needs some love to become
production ready. There has to be a re-focus for some time. PHP
5.2-5.3 where a good example of cleaning up, speeding up and very good
feature development - anonymous functions for example are just
freaking awesome stuff.
It is a good idea to look at all the big stuff that is just begging to
be fixed/added/done - Unicode is really the pain in the ass
(especially for me, because I have to work with multi-language
websites and systems - Russian, Latvian, English, Arabic and other).
There just has to be some sort of core developer decision to stop
actively developing new features and just clean up the backlog.
Community probably will follow with that too.
Hi!
Well, there is the impact, but seriously, do that many people will use
it in production? I certainly will not, but on the DEV and on my local
development machine it will be enabled period.
Everybody would be using that in production. Production is where the
danger is, nobody would break into developer machine since nobody can
access it except for developers!
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
so the problem is, that the userland is under-represented in the
development, because they usually not present on the mailing list and on
irc, where discussions and decisions happen, and they usually have
different
priorities and expectations about the PHP language than the core devs.
to make things worse, they cannot write patches for the core, and the core
devs rarely work on something which they don't particularly need or like.and I think that the only option where we can change that, is that us, the
php userland devs has to be more active on the mailing lists, irc, bug
tracking, writing RFCs etc.
Why not open a Google Groups list?, having every message recorded publicly
and being easy to join-in I'd bet that the situation would change. I've seen
it work really well for other open source projects, such as Joomla and
Symfony.
Regards,
David Vega
Hi all,
Based on an extensive chat with Matthew, I think we reached some consensus.
I'll write another RFC related to Annotations in docblocks, then we
can chat until reach some standardization and availability.
Regards,
so the problem is, that the userland is under-represented in the
development, because they usually not present on the mailing list and on
irc, where discussions and decisions happen, and they usually have
different
priorities and expectations about the PHP language than the core devs.
to make things worse, they cannot write patches for the core, and the core
devs rarely work on something which they don't particularly need or like.and I think that the only option where we can change that, is that us, the
php userland devs has to be more active on the mailing lists, irc, bug
tracking, writing RFCs etc.Why not open a Google Groups list?, having every message recorded publicly
and being easy to join-in I'd bet that the situation would change. I've seen
it work really well for other open source projects, such as Joomla and
Symfony.Regards,
David Vega
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
On Tue, May 10, 2011 at 9:31 PM, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:
Hi all,
Based on an extensive chat with Matthew, I think we reached some consensus.
I'll write another RFC related to Annotations in docblocks, then we
can chat until reach some standardization and availability.Regards,
glad to hear that.
Tyrael
On Tue, May 10, 2011 at 9:28 PM, dukeofgaming dukeofgaming@gmail.comwrote:
so the problem is, that the userland is under-represented in the
development, because they usually not present on the mailing list and on
irc, where discussions and decisions happen, and they usually have
different
priorities and expectations about the PHP language than the core devs.
to make things worse, they cannot write patches for the core, and the core
devs rarely work on something which they don't particularly need or like.and I think that the only option where we can change that, is that us, the
php userland devs has to be more active on the mailing lists, irc, bug
tracking, writing RFCs etc.Why not open a Google Groups list?, having every message recorded publicly
and being easy to join-in I'd bet that the situation would change. I've seen
it work really well for other open source projects, such as Joomla and
Symfony.
you can already do that through http://marc.info/?l=php-internals or the
newsgroup, see http://php.net/mailing-lists.php
albeit google groups is better imho
Tyrael
On Tue, May 10, 2011 at 9:28 PM, dukeofgaming dukeofgaming@gmail.comwrote:
so the problem is, that the userland is under-represented in the
development, because they usually not present on the mailing list and on
irc, where discussions and decisions happen, and they usually have
different
priorities and expectations about the PHP language than the core devs.
to make things worse, they cannot write patches for the core, and the
core
devs rarely work on something which they don't particularly need or like.and I think that the only option where we can change that, is that us,
the
php userland devs has to be more active on the mailing lists, irc, bug
tracking, writing RFCs etc.Why not open a Google Groups list?, having every message recorded publicly
and being easy to join-in I'd bet that the situation would change. I've seen
it work really well for other open source projects, such as Joomla and
Symfony.you can already do that through http://marc.info/?l=php-internals or the
newsgroup, see http://php.net/mailing-lists.php
albeit google groups is better imhoTyrael
Yeah, I forgot to mention that everything is threaded there, so its easier
to follow.
Regards,
David Vega
Hi!
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.
Of course we are interested in user's requests, and we implemented tons
of features at user's requests. That, however, does not mean we will
implement every requested feature, and of course for features that we
like and understand the chance of being implemented are much higher and
for features that core contributors don't feel make sense or go contrary
to what they feel PHP should be the chance is low. I don't think it can
work any other way, at least not in volunteer-driven project.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Stas Malyshev wrote:
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.Of course we are interested in user's requests, and we implemented tons
of features at user's requests. That, however, does not mean we will
implement every requested feature, and of course for features that we
like and understand the chance of being implemented are much higher and
for features that core contributors don't feel make sense or go contrary
to what they feel PHP should be the chance is low. I don't think it can
work any other way, at least not in volunteer-driven project.
I do feel it is about time there was a little back-pedalling and asking 'What do
we NEED in PHP'. Personally a lot of the things that are been 'demanded' are of
little use to make PHP work any better, and only add to the processing time. If
people want a fully typed compiled language why aren't they using python or java
;) My own development framework is phpeclipse, and that give me all of the
hinting and error checking that I need IN THE EDITOR, I don't need the language
weight down further with bells and whistles that do not improve performance of
the end application. PHP used to be a nice nimble interpreted language that I
can add pages to without having to compile anything. Nowadays it seems that
those days are coming to an end? Keep the hinting and error checking to the
tools where they belong.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/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
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.
Rasmus & Stas have already pointed out this is not valid and lots of
user requests are implemented.
I'd add that PHP has never had a lot of spare developer capacity.
Programmers are not idly sitting around, waiting for random ideas to
code up. If you feel strongly about a feature you have to convince
the core contributors of its merits and (i) pique the interest of
someone capable of implementing it and then help with testing and
documentation, or (ii) implement it all yourself.
It's easier than ever to get an SVN account, so contributing would
be a good way to get karma.
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
-----Original Message-----
From: Christopher Jones [mailto:christopher.jones@oracle.com]
Sent: Monday, May 09, 2011 10:28 AM
To: internals@lists.php.net; Guilherme Blanco
Subject: Re: [PHP-DEV] 5.4 again
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.
Rasmus & Stas have already pointed out this is not valid and lots of user
requests are implemented.
I'd add that PHP has never had a lot of spare developer capacity.
Programmers are not idly sitting around, waiting for random ideas to code
up. If you feel strongly about a feature you have to convince the core
contributors of its merits and (i) pique the interest of someone capable of
implementing it and then help with testing and documentation, or (ii)
implement it all yourself.
It's easier than ever to get an SVN account, so contributing would be a good
way to get karma.
I agree but also want to emphasize that just because there’s a patch it doesn’t mean it’s a good idea and should be accepted.
Of course like Chris points out it’ll significantly increase the chances of people taking it seriously and playing around with the idea.
I also think Matthew makes a good point – annotations can be viewed in different ways and arguably there are already quite a lot of possibilities with what exists today.
Andi
Hi Andi,
That's all I want.
Someone to at least look at the patch and give me feedback.
None here did that, all you're doing is telling "no, we don't accept it".
Why don't you give me some valuable feedback so I can work on the
patch to turn it relevant to you?
Regards,
-----Original Message-----
From: Christopher Jones [mailto:christopher.jones@oracle.com]
Sent: Monday, May 09, 2011 10:28 AM
To: internals@lists.php.net; Guilherme Blanco
Subject: Re: [PHP-DEV] 5.4 again
It seems to me that you are not interested on user's request and
rather accept/implement only what the features that interest you. It's
very bad for the language and very bad for all of users.
Rasmus & Stas have already pointed out this is not valid and lots of user
requests are implemented.
I'd add that PHP has never had a lot of spare developer capacity.
Programmers are not idly sitting around, waiting for random ideas to code
up. If you feel strongly about a feature you have to convince the core
contributors of its merits and (i) pique the interest of someone capable
ofimplementing it and then help with testing and documentation, or (ii)
implement it all yourself.
It's easier than ever to get an SVN account, so contributing would be a
goodway to get karma.
I agree but also want to emphasize that just because there’s a patch it
doesn’t mean it’s a good idea and should be accepted.Of course like Chris points out it’ll significantly increase the chances of
people taking it seriously and playing around with the idea.I also think Matthew makes a good point – annotations can be viewed in
different ways and arguably there are already quite a lot of possibilities
with what exists today.Andi
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Monday, May 09, 2011 10:51 AM
To: Andi Gutmans
Cc: Christopher Jones; internals@lists.php.net
Subject: Re: [PHP-DEV] 5.4 again
Hi Andi,
That's all I want.
Someone to at least look at the patch and give me feedback.
None here did that, all you're doing is telling "no, we don't accept it".
Why don't you give me some valuable feedback so I can work on the patch to
turn it relevant to you?
I think more important than the patch is the actual functionality. Patch can always be fixed.
I assume the latest RFC is https://wiki.php.net/rfc/annotations?
I will take a bit of a longer look at it in the coming days but from looking at it quickly I can see why some people may not be very excited about it. I personally have never been a huge fan of meta-data whether in the code or outside the code. The biggest scars I carry are from J2EE. I feel annotations are sometimes just a nicer way of creating similar problems (hard to understand flow, hard to debug, etc…). I do realize there are also some benefits but as Matthew pointed out the question is are those benefits enough to warrant a whole new grammar in the language or do we keep it lighter weight and let people build on that (which with the right caching should not be too hard).
Anyway, I will take a longer look.
Andi (hoping I don’t get extra newlines this time around. My apologies but for some reason my mail client doesn’t like internals@ in the past two weeks).
Hi Andi,
Sorry, but I mentioned on other thread that RFC is outdated.
I just finished an update to it bringing to recent implementation. The
idea is to get the "big picture" here, I may have left from previous
RFC, but if I did that, please just point out and I can fix.
This implementation is way simpler.
Here is the direct link: https://wiki.php.net/rfc/annotations
Regards,
-----Original Message-----
From: guilhermeblanco@gmail.com [mailto:guilhermeblanco@gmail.com]
Sent: Monday, May 09, 2011 10:51 AM
To: Andi Gutmans
Cc: Christopher Jones; internals@lists.php.net
Subject: Re: [PHP-DEV] 5.4 again
Hi Andi,
That's all I want.
Someone to at least look at the patch and give me feedback.
None here did that, all you're doing is telling "no, we don't accept it".
Why don't you give me some valuable feedback so I can work on the patch to
turn it relevant to you?
I think more important than the patch is the actual functionality. Patch can
always be fixed.I assume the latest RFC is https://wiki.php.net/rfc/annotations?
I will take a bit of a longer look at it in the coming days but from looking
at it quickly I can see why some people may not be very excited about it. I
personally have never been a huge fan of meta-data whether in the code or
outside the code. The biggest scars I carry are from J2EE. I feel
annotations are sometimes just a nicer way of creating similar problems
(hard to understand flow, hard to debug, etc…). I do realize there are also
some benefits but as Matthew pointed out the question is are those benefits
enough to warrant a whole new grammar in the language or do we keep it
lighter weight and let people build on that (which with the right caching
should not be too hard).Anyway, I will take a longer look.
Andi (hoping I don’t get extra newlines this time around. My apologies but
for some reason my mail client doesn’t like internals@ in the past two
weeks).
--
Guilherme Blanco
Mobile: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
São Paulo - SP/Brazil
Hi Andi,
Sorry, but I mentioned on other thread that RFC is outdated.
I just finished an update to it bringing to recent implementation. The
idea is to get the "big picture" here, I may have left from previous
RFC, but if I did that, please just point out and I can fix.
This implementation is way simpler.Here is the direct link: https://wiki.php.net/rfc/annotations
As for positive feedback, it's a net improvement over the previous RFC and I like the simplifications.
Is there really a need for:
Array ::= "array(" ArrayEntry {"," ArrayEntry}* ")"
Do you have examples of where that's needed?
Hi!
- ReflectionNamespace
- Annotations
- SplArray
- Comparable
Thanks for the list, it's a good start of the discussion. I have only
one note for now - since the goal of all this to try and get 5.4 out
before the end of the year, I think that requires some scope limiting.
By this I mean that if something is proposed to which the implementation
or design isn't obvious, there should be commitment for it to be done in
next 2 months. By "done" I mean both having design with reasonable
consensus and full implementation.
So if somebody proposes something entirely new that the implementation
is not obvious or already existing, he should either make commitment to
do this in the next 2 months personally or find somebody who will. Of
course, 2 months here doesn't mean exactly 61 days, but it's the
timeframe. I.e., if it's an idea "let's somebody do it" - it might be a
perfectly good idea, but not for this 5.4. That doesn't mean it's
rejected - it just would be out of scope for this release.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I see the array shortcuts are on your todo discussion list there. We
probably shouldn't get into a full discussion on that since it will span
hundreds of messages. But if any of the folks who voted no last time
around have changed their minds, it would be good to know. And before
deciding, try using MongoDB from PHP for a couple of weeks. :)I agree on both discussion point and MongoDB point :) I think for things that were already discussed extensively it makes sense to have a vote in case people changed their minds and discuss at length only if they have something new to say - like proposing new approach to the problem - which is this case probably won't happen.
I'm changing my old vote, so -1 to +1. Changes and additions to syntax may (or may not) slow adoption, but since other such changes are being made then let's do it. And while explicit code (e.g., array()) is nice, many people are familiar with array shortcuts[1].
And on a related note for those at home, function array dereferencing[2] has already been implemented in trunk.
Also, there could probably be a discussion dedicated to arrays as other features/shortcuts like slicing has casually been discussed.
[1] https://wiki.php.net/rfc/shortsyntaxforarrays
[2] https://wiki.php.net/rfc/functionarraydereferencing
Regards,
Philip
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Sunday, May 08, 2011 4:41 PM
To: PHP Internals
Subject: [PHP-DEV] 5.4 again
Hi!
I has been almost a month since we did our routine talk about 5.4, so here it
goes again. The patch for the scalar hints seems to be pretty simple (see
http://random-bits-of.info/no_scalar_hints.diff - no generated files included,
that will be done on actual commit), so it should not hold us too much.
I propose putting current code in a branch and continue without scalar typing
for 5.4 - any objections to that?
-snip-
I think we need to start moving. Not much is happening in 5.4 now as far as I
can see, and we have a good feature set that is long due to be released.
For proposing stuff for 5.4, please do it here:
https://wiki.php.net/todo/php54 and also on the list if it wasn't discussed and
you think it requires discussion.
As I've already pointed out, I am all in favor of starting to run the release process.
I do think we should focus on getting out there what we have now (with some tweaks) and not trying to do major new features or we will by definition not be entering a release process. The richer our language (and the more mature and broad our base) the more we have to be concerned with feature creep.
-
On performance & memory consumption - as already mentioned, huge improvements! We may be able to do more but will stay within the release timeline if we make any further improvements.
-
On square bracket shortcut I was always in favor of (b) in http://marc.info/?l=php-internals&m=119999385524494&w=2. If this is what we're talking about I personally feel it's an easy one.
-
Agree type hints goes out.
Go!!
Andi
Seems like a good plan to me. Hopefully as per schedule it gets us 5.4
this year.
Hi!
I has been almost a month since we did our routine talk about 5.4, so here
it goes again. The patch for the scalar hints seems to be pretty simple (see
http://random-bits-of.info/no_scalar_hints.diff - no generated files
included, that will be done on actual commit), so it should not hold us too
much.
I propose putting current code in a branch and continue without scalar
typing for 5.4 - any objections to that?I would like to propose the following process (of course, dates can be moved
around, etc. - I consider phase lengths be more important that actual dates,
but any of them can be shifted if reason arises) for 5.4:
- starting now - nominate features for 5.4 (see
https://wiki.php.net/todo/php54), discussion on them- May 18 - start voting and debating on features that have no clear
consensus support immediately. On the end of May is also phptek, so we could
have some discussion there about it if needed.- June 15 (a bit more than a month) - alpha, branching of 5_4, open only for
bugfixes and features in TODO list that are approved and can be done by beta
time.- July 20 - beta, bugfixes only (if we add a lot of features, we may want to
insert another 1-month alpha period, so far it doesn't look like it but may
change)- Aug 24 - RC1, then an RC every 2 weeks until stable
- Release - somewhere in October or November, depending on the RCs.
I think we need to start moving. Not much is happening in 5.4 now as far as
I can see, and we have a good feature set that is long due to be released.
For proposing stuff for 5.4, please do it here:
https://wiki.php.net/todo/php54 and also on the list if it wasn't discussed
and you think it requires discussion.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Sunday, May 08, 2011 4:41 PM
To: PHP Internals
Subject: [PHP-DEV] 5.4 againHi!
I would like to propose the following process (of course, dates can be moved
around, etc. - I consider phase lengths be more important that actual dates, but
any of them can be shifted if reason arises) for 5.4:
- starting now - nominate features for 5.4 (see https://wiki.php.net/todo/php54),
discussion on them- May 18 - start voting and debating on features that have no clear consensus
support immediately. On the end of May is also phptek, so we could have some
discussion there about it if needed.- June 15 (a bit more than a month) - alpha, branching of 5_4, open only for
bugfixes and features in TODO list that are approved and can be done by beta
time.- July 20 - beta, bugfixes only (if we add a lot of features, we may want to insert
another 1-month alpha period, so far it doesn't look like it but may change)- Aug 24 - RC1, then an RC every 2 weeks until stable
- Release - somewhere in October or November, depending on the RCs.
I think we need to start moving. Not much is happening in 5.4 now as far as I can
see, and we have a good feature set that is long due to be released.
Stas, in the past we had alphas. Is there any reason why we wouldn't roll one out asap? (revert the typehints stuff and go).
I think we (almost) all agree that we need to start pushing PHP 5.4 with all the goodness that has been developed "to-date". Additional features can wait for the next version.
Any exceptions that are low risk can be evaluated (an additional minor API, some additional enhancements) but let's get the good work that has been done to-date out there vs. allowing feature creep and pushing the timeline for another 1-2 years. I think we should start pushing out alpha in parallel to these discussions. Most of them sound like major features which would not make PHP 5.4 as any major feature requires plenty of time to mature (and needless to say some of them won't even be accepted).
There is plenty to get excited about in PHP 5.4!
Andi (sending in plaintext. Hope this gets rid of the funky newlines from prior emails)
I think an idea of an alpha right away is a good one. I feel we
definitely have enough "stuff" in HEAD branch right now for 5.4 +/-
few minor changes. It should also be a good boost to getting people on
track that 5.4 is a go.
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Sunday, May 08, 2011 4:41 PM
To: PHP Internals
Subject: [PHP-DEV] 5.4 againHi!
I would like to propose the following process (of course, dates can be moved
around, etc. - I consider phase lengths be more important that actual dates, but
any of them can be shifted if reason arises) for 5.4:
- starting now - nominate features for 5.4 (see https://wiki.php.net/todo/php54),
discussion on them- May 18 - start voting and debating on features that have no clear consensus
support immediately. On the end of May is also phptek, so we could have some
discussion there about it if needed.- June 15 (a bit more than a month) - alpha, branching of 5_4, open only for
bugfixes and features in TODO list that are approved and can be done by beta
time.- July 20 - beta, bugfixes only (if we add a lot of features, we may want to insert
another 1-month alpha period, so far it doesn't look like it but may change)- Aug 24 - RC1, then an RC every 2 weeks until stable
- Release - somewhere in October or November, depending on the RCs.
I think we need to start moving. Not much is happening in 5.4 now as far as I can
see, and we have a good feature set that is long due to be released.Stas, in the past we had alphas. Is there any reason why we wouldn't roll one out asap? (revert the typehints stuff and go).
I think we (almost) all agree that we need to start pushing PHP 5.4 with all the goodness that has been developed "to-date". Additional features can wait for the next version.
Any exceptions that are low risk can be evaluated (an additional minor API, some additional enhancements) but let's get the good work that has been done to-date out there vs. allowing feature creep and pushing the timeline for another 1-2 years. I think we should start pushing out alpha in parallel to these discussions. Most of them sound like major features which would not make PHP 5.4 as any major feature requires plenty of time to mature (and needless to say some of them won't even be accepted).There is plenty to get excited about in PHP 5.4!
Andi (sending in plaintext. Hope this gets rid of the funky newlines from prior emails)
Stas, in the past we had alphas. Is there any reason why we wouldn't
roll one out asap? (revert the typehints stuff and go).
+1
johannes
Stas, in the past we had alphas. Is there any reason why we wouldn't
roll one out asap? (revert the typehints stuff and go).+1
Waiting a month or two longer is worth it, especially considering the 5.4 momentum feels real this time around. We're creating a real TODO, and have a real tentative timeline, so forcing a premature alpha at this point (thus closing off feature/api discussion) is a bad idea. A big -1 here. I mean, we may as well get it right since we've waited so long already.
Regards,
Philip
Hi!
Waiting a month or two longer is worth it, especially considering the
5.4 momentum feels real this time around. We're creating a real TODO,
and have a real tentative timeline, so forcing a premature alpha at
this point (thus closing off feature/api discussion) is a bad idea. A
big -1 here. I mean, we may as well get it right since we've waited
so long already.
I don't think it's closing feature discussion. We can have another alpha
after the discussion, or more than one. I can see the value of having
something right now to signify we mean it this time, but that
something would definitely not be anything near final and we can take
features in after the discussion is done.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Waiting a month or two longer is worth it, especially considering the
5.4 momentum feels real this time around. We're creating a real TODO,
and have a real tentative timeline, so forcing a premature alpha at
this point (thus closing off feature/api discussion) is a bad idea. A
big -1 here. I mean, we may as well get it right since we've waited
so long already.I don't think it's closing feature discussion. We can have another alpha after the discussion, or more than one. I can see the value of having something right now to signify we mean it this time, but that something would definitely not be anything near final and we can take features in after the discussion is done.
The alpha release proposal by Andi contains the text:
"I think we (almost) all agree that we need to start pushing PHP 5.4 with all the goodness that has been developed "to-date". Additional features can wait for the next version."
So, that's the concern there. But if the alpha is simply a trick to convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do it. ;)
Regards,
Philip
So, that's the concern there. But if the alpha is simply a trick to convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do it. ;)
There are still quite a few test failures in trunk. Some of them are
also in the 5_3 branch. In some cases the tests are simply bad. In a few
the test case contains binary data that got mangled in the move to
Subversion. It would be nice if just 1 in 10 people reading the list
here would grab both trunk and 5_3 and run "make test" in each tree and
then fix at least 1 test each. We would have no test failures by the end
of the day other than a few tricky ones. If an alpha release will
encourage this, great. If we could get people to just do it on their own
without the alpha, even better.
And yes, I know the tests take forever to run. Get yourself a fast
machine with an SSD, and remember you can run partial tests using:
make test TESTS=ext/hash
for example to just run the tests for the hash extension.
Also, when a test fails, cd into the ext/hash/tests directory and you
will see .out, .exp, .diff and .php files for the failed test. That is,
the output, the expected output, the diff between them and the php
script itself extracted from the .phpt file containing the failed test case.
And if you can't figure out how to fix a test, post the details here.
I'd love to point some of the obvious talents and energy of this list
towards the code. If you don't have an svn account for committing your
fixed test, go to http://www.php.net/svn-php.php and fill in the little
form at the bottom there and put in the test that you fixed and a
1-liner about how you fixed it and I will set you up with an account
right away. Info on how to check out the code from svn is here:
https://wiki.php.net/vcs/svnfaq
-Rasmus
So, that's the concern there. But if the alpha is simply a trick to convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do it. ;)
There are still quite a few test failures in trunk. Some of them are also in the 5_3 branch. In some cases the tests are simply bad. In a few the test case contains binary data that got mangled in the move to Subversion. It would be nice if just 1 in 10 people reading the list here would grab both trunk and 5_3 and run "make test" in each tree and then fix at least 1 test each. We would have no test failures by the end of the day other than a few tricky ones. If an alpha release will encourage this, great. If we could get people to just do it on their own without the alpha, even better.
And yes, I know the tests take forever to run. Get yourself a fast machine with an SSD, and remember you can run partial tests using:
make test TESTS=ext/hash
for example to just run the tests for the hash extension.
Also, when a test fails, cd into the ext/hash/tests directory and you will see .out, .exp, .diff and .php files for the failed test. That is, the output, the expected output, the diff between them and the php script itself extracted from the .phpt file containing the failed test case.
And if you can't figure out how to fix a test, post the details here. I'd love to point some of the obvious talents and energy of this list towards the code. If you don't have an svn account for committing your fixed test, go to http://www.php.net/svn-php.php and fill in the little form at the bottom there and put in the test that you fixed and a 1-liner about how you fixed it and I will set you up with an account right away. Info on how to check out the code from svn is here:
https://wiki.php.net/vcs/svnfaq
This is a great challenge. Long ago I decided that failed tests are expected in PHP, because out of the ~100 or so times I've run it these past n years, it has always (afair) failed. Changing this fact by having it pass would change peoples (at least my) perception that running 'make test' is a waste of time, as is (was) looking into why they failed. For example, just now trunk gives me 55 failed tests and 17 expected fails with a vanilla build.
We once had a matrix showing test results per setup (OS, phpversion, per configure switches) but it was someones pet project and the code has long since been lost (he looked years ago). Maybe such a beast would be useful.
Also, how about we change[1] it so php.qa.reports[2] stops receiving 5_2 results, and always receives snapshot results? For example, snapshot test results (5_3 and trunk) are configured to not go there today.
Regards,
Philip
[1] http://svn.php.net/viewvc/web/qa/trunk/include/release-qa.php
[2] http://news.php.net/php.qa.reports
Hi!
We once had a matrix showing test results per setup (OS, phpversion,
per configure switches) but it was someones pet project and the code
has long since been lost (he looked years ago). Maybe such a beast
would be useful.
We can do a table saying which tests fails where in the wiki right now...
Also, how about we change[1] it so php.qa.reports[2] stops receiving
5_2 results, and always receives snapshot results? For example,
snapshot test results (5_3 and trunk) are configured to not go
there today.
I think it's an excellent idea. 5.2 is not going to be fixed anyway, we
need 5.3 and trunk much more.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
We once had a matrix showing test results per setup (OS, phpversion,
per configure switches) but it was someones pet project and the code
has long since been lost (he looked years ago). Maybe such a beast
would be useful.We can do a table saying which tests fails where in the wiki right now...
Okay let's have a look after we receive more reports. And collaboration may be needed for several of these fails although opening a bug report for each doesn't feel ideal. Other ideas? A "I tried this, it may be that, my OS is weird, ah I see, oh nice idea let's try... Eureka!" type dialogue comes to mind.
Also, how about we change[1] it so php.qa.reports[2] stops receiving
5_2 results, and always receives snapshot results? For example,
snapshot test results (5_3 and trunk) are configured to not go
there today.I think it's an excellent idea. 5.2 is not going to be fixed anyway, we need 5.3 and trunk much more.
I replaced 5.2 with 5.4 for FC, and we now allow 5.3.7-dev and 5.3.99-dev snaps. However, I'm unable to determine why 5.3.99-dev tests aren't posting to the list but at least 5.3.7-dev do now. Speaking of 5.3.99, how about we rename it to 5.4? The trunk being 5.4 or 6.0 debate feels over. ;)
Regards,
Philip
Hi, list.
I've fixed some datetime tests in the trunk in answer to "Rasmus call
for devs" :)
There are two patches here.
First patch is quite trivial - it fixes some relative/absolute path
misconfiguration in phpt tests.
Second patch fixes some timezone errors in bug51819 - some timezones
like GB were not parsed correctly. Tests are ok now but don't know if
my solution is correct.
Hope these patches would be useful.
P.S. Please, note I'm very new to C and will be happy if someone can
answer to some of my newbie questions and gently point my mistakes :)
2011/5/12 Rasmus Lerdorf rasmus@lerdorf.com:
So, that's the concern there. But if the alpha is simply a trick to
convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is
real, then do it. ;)There are still quite a few test failures in trunk. Some of them are also in
the 5_3 branch. In some cases the tests are simply bad. In a few the test
case contains binary data that got mangled in the move to Subversion. It
would be nice if just 1 in 10 people reading the list here would grab both
trunk and 5_3 and run "make test" in each tree and then fix at least 1 test
each. We would have no test failures by the end of the day other than a few
tricky ones. If an alpha release will encourage this, great. If we could get
people to just do it on their own without the alpha, even better.And yes, I know the tests take forever to run. Get yourself a fast machine
with an SSD, and remember you can run partial tests using:make test TESTS=ext/hash
for example to just run the tests for the hash extension.
Also, when a test fails, cd into the ext/hash/tests directory and you will
see .out, .exp, .diff and .php files for the failed test. That is, the
output, the expected output, the diff between them and the php script itself
extracted from the .phpt file containing the failed test case.And if you can't figure out how to fix a test, post the details here. I'd
love to point some of the obvious talents and energy of this list towards
the code. If you don't have an svn account for committing your fixed test,
go to http://www.php.net/svn-php.php and fill in the little form at the
bottom there and put in the test that you fixed and a 1-liner about how you
fixed it and I will set you up with an account right away. Info on how to
check out the code from svn is here:
https://wiki.php.net/vcs/svnfaq-Rasmus
--
--
Regards,
Shein Alexey
It seems Rasmus already patched some date tests here:
http://svn.php.net/viewvc?view=revision&revision=311014
And my second patch (in previous letter) about bug 51819 is wrong,
will try to investigate it further.
More test fixes:
/trunk/ext/curl/tests/curl_setopt_basic001.phpt should probably be
deleted, since it checked curl behavior in safe_mode and there's no
safe_mode anymore in trunk.
/trunk/ext/date/tests/DateInterval_format_a.phpt needs timezone set
(see attached patch)
/trunk/ext/session/tests/session_encode_basic.phpt - needs precision
serialize to be set (see attached patch)
I need some help with another bug. I'm looking into curl bug
http://bugs.php.net/48203 (test /trunk/ext/curl/tests/bug48203.phpt).
The bug is when std_err file pointer given to curl is closed before
calling curl_exec then curl causes segfault. How I can check that file
is already closed? File pointer is stored in zval as I can see
(ch->handlers->std_err in /ext/curl/interface.c around line 1852) .
2011/5/13 Alexey Shein confik@gmail.com:
Hi, list.
I've fixed some datetime tests in the trunk in answer to "Rasmus call
for devs" :)
There are two patches here.
First patch is quite trivial - it fixes some relative/absolute path
misconfiguration in phpt tests.
Second patch fixes some timezone errors in bug51819 - some timezones
like GB were not parsed correctly. Tests are ok now but don't know if
my solution is correct.
Hope these patches would be useful.P.S. Please, note I'm very new to C and will be happy if someone can
answer to some of my newbie questions and gently point my mistakes :)2011/5/12 Rasmus Lerdorf rasmus@lerdorf.com:
So, that's the concern there. But if the alpha is simply a trick to
convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is
real, then do it. ;)There are still quite a few test failures in trunk. Some of them are also in
the 5_3 branch. In some cases the tests are simply bad. In a few the test
case contains binary data that got mangled in the move to Subversion. It
would be nice if just 1 in 10 people reading the list here would grab both
trunk and 5_3 and run "make test" in each tree and then fix at least 1 test
each. We would have no test failures by the end of the day other than a few
tricky ones. If an alpha release will encourage this, great. If we could get
people to just do it on their own without the alpha, even better.And yes, I know the tests take forever to run. Get yourself a fast machine
with an SSD, and remember you can run partial tests using:make test TESTS=ext/hash
for example to just run the tests for the hash extension.
Also, when a test fails, cd into the ext/hash/tests directory and you will
see .out, .exp, .diff and .php files for the failed test. That is, the
output, the expected output, the diff between them and the php script itself
extracted from the .phpt file containing the failed test case.And if you can't figure out how to fix a test, post the details here. I'd
love to point some of the obvious talents and energy of this list towards
the code. If you don't have an svn account for committing your fixed test,
go to http://www.php.net/svn-php.php and fill in the little form at the
bottom there and put in the test that you fixed and a 1-liner about how you
fixed it and I will set you up with an account right away. Info on how to
check out the code from svn is here:
https://wiki.php.net/vcs/svnfaq-Rasmus
--
--
Regards,
Shein Alexey
--
Regards,
Shein Alexey
Question from the peanut gallery. Is the removal of magic_quotes and
register_globals going to be done on this release, or is that still being
put off for PHP 6?
Hi
2011/5/16 Michael Morris dmgx.michael@gmail.com:
Question from the peanut gallery. Is the removal of magic_quotes and
register_globals going to be done on this release, or is that still being
put off for PHP 6?
So far all the legacy features have been removed from 5.4, except
magic_quotes which still is pending for discussion. See [1] for more
information about the removed features.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hi:
The alpha release proposal by Andi contains the text:
"I think we (almost) all agree that we need to start pushing PHP 5.4 with all the goodness that has been developed "to-date". Additional features can wait for the next version."
So, that's the concern there. But if the alpha is simply a trick to convince people to test out a specific PHP 5.4 snapshot, and feel 5.4 is real, then do it. ;)
+1 that would definitely demonstrate the ability to get moving again.
An important sign to the larger community.
However, the stability/instability of the feature set should be clearly defined.
Thanks
Stefan
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
+1
+1
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Hi!
Stas, in the past we had alphas. Is there any reason why we wouldn't
roll one out asap? (revert the typehints stuff and go).
OK, I can do the stuff (typehints, branch, tag) on the weekend. I don't
know how to roll the packages & do the mails though, so if somebody
could volunteer there it'd be great :)
Some of the proposed changes though are not BC-safe, so we should warn
people that this alpha is not the fixed API yet.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Stas, in the past we had alphas. Is there any reason why we wouldn't
roll one out asap? (revert the typehints stuff and go).OK, I can do the stuff (typehints, branch, tag) on the weekend. I don't
know how to roll the packages & do the mails though, so if somebody
could volunteer there it'd be great :)
Most parts (all?) is documented in README.RELEASE_PROCESS I can assist.
johannes
Hi!
Most parts (all?) is documented in README.RELEASE_PROCESS I can assist.
Thanks!
Interestingly enough, this file still refers to CVS in trunk. I guess
somebody familiar with up-to-date process has to update it :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Most parts (all?) is documented in README.RELEASE_PROCESS I can assist.
Thanks!
Interestingly enough, this file still refers to CVS in trunk. I guess
somebody familiar with up-to-date process has to update it :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227