On 9/5/13 3:32 AM, Pierre Joye wrote:
On Thu, Sep 5, 2013 at 11:34 AM, Nikita Popov <nikita....@gmail.com> wrote:
On Thu, Sep 5, 2013 at 10:51 AM, Pierre Joye <pierre....@gmail.com> wrote:
On Thu, Sep 5, 2013 at 10:23 AM, Sebastian Krebs <krebs....@gmail.com>
wrote:
That being said, there is always a point in a RFC discussion where
there is nothing left to discuss or argue about, we are so far with
this one.
We've been at this point for a while; no new arguments have been raised
despite several people asking to bring it back in focus.
I totally understand your view on how such discussions go. However it
was (for what I read) about technical issues and the tones were
correct, could have been more diplomatic but that's fine imho. I am
not sure how to solve this problem as we have to discuss things deeply
and be sure that active core developers actually understand all the
impact of a given proposal will have, that's a must.
I don't think this discussion was about technical issues. Let me summarize
the main discussion points:
* "This will make function calls slower!". Many complaints about this
change hurting performance, even though it was pointed out early on (and
detailed in the RFC) that this is not true.
* "Will you put every function in it's own file?!". This has been repeated
*a lot* in this thread, even though again it has been pointed out early that
there are more reasonable autoloading schemes for functions (e.g.
namespace-to-file)
* "Just use static methods instead". I don't need to comment on the
absurdity of this statement.
* "Which function is autoloaded?" Is the namespaced version or the global
fallback loaded?
Of these, only the last point has been of any benefit to this discussion.
There has also been some minor discussion regarding the API, which is also
relevant. But why does 80% of this thread deal with performance (known
incorrect assumption), unreasonable suggestions of function-to-file mappings
(even though alternatives are known) and suggestions to just not use
functions? It's really hard to fish out the 10 relevant mails in a
discussion spanning 70 in total.
Right, it goes circular way too often. I see that in many other MLs. I
however do not see it as a reason to leave, no matter how much it
happens. I also see these questions, discussions or arguing session as
technical matters, be semantic, common sense or anything else. It is
all about being sure about what php will be after a given feature is
added.
I'm pretty sure that Anthony's reaction is not directly related to this
particular thread - rather it is an accumulation of the very same kind of
discussion we have on nearly every RFC. Discussion is always very circular,
covering issues that have already been addressed (usually even written down
in the RFCs). Typically this kind of pointless discussion happens between
just three or so people and fills the largest part of the thread. Stas is
usually one of those "three" people, though of course I will not imply
causation from correlation.
I very much respect Stas, both for his constructive attitude and the
insane amount of work he puts in PHP and the related projects. As
anyone else, he is however a human, with needs to understand a
specific point very clearly. I do not think there any evil or
domination behavior here. About the N people trying to control
everything, that's why we have RFCs. Maybe we should scan discussions
more frequently and stop them when it goes circular, ask to update the
RFC accordingly and move forward. This is something I tried to do.
Sadly I was busy with other stuff in the last couple of months and was
not able to follow each recent RFC discussions closely.
Cheers,
I agree with Pierre on all his points in this mail.
(Note I haven't done more than skim the fuss around "the post I wish I
didn't have to read" so I won't comment further, nor wish my thoughts
to be extrapolated in any related direction).
Chris
--
christopher.jo...@oracle.com http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
