At 15:14 11/08/2010, Richard Quadling wrote:
On 11 August 2010 12:10, Zeev Suraski <z...@zend.com> wrote:
> We need to remove strict typing from trunk before we release anything
> 'official' from php.net
I thought "trunk" is, to some degree, the "work in progress" /
"developers only", YMMV branch. Pretty much anything/everything in
there is subject to change. No money back guarantees. Etc.
Supposedly we switched to this strategy although I'm not sure why,
nor I recall any discussion about it - although I may have missed
it. We never ever treated HEAD this way in the CVS days. So sure,
now it's called 'trunk', but why we should deviate from our decision
making processes (as lax as they may be) because we changed version
control systems is beyond me.
For an official release, even as a "Here is what we are working on. It
might not be perfect, but we like it" release, a separate branch would
be created.
It's really not a matter of branches, trunk or HEAD. It's a matter
of what 'php.net' puts its virtual stamp of approval on. If 5.4
alpha 1 came out with strict typing in it, it would send two very
strong messages to the PHP community:
1. The next version of PHP is going to be named 5.4 - something that
wasn't agreed upon (although personally I don't mind that much).
2. "We think strict typing is a good idea, here, play with
it". Well, turns out that the collective 'we' doesn't really think
that at all. It's no big news either, it's been known for many months.
That goes back to my first paragraph. Personally, I don't like the
'shoot first, ask questions later' approach that we supposedly
switched to recently. To me it makes a whole lot more sense to
discuss first, and only once a decision is made - go ahead and
implement it. Whether we go formal with RFCs or less formal on
internals@ (depending on the scope) - either way it's way better than
committing first and only then discussing. Once in trunk we suddenly
need a great reason to remove it, since trunk is now the new 'status
quo'. Thankfully in the case of strict typing there was a strong,
clear message from the community 'don't do it', but what about
smaller features?
'Shoot first, ask questions later' equates 'bias for change'. Is
that where we want to be? IMHO no, we should carefully consider
every change we make to the core language at this point in time.
Maybe I'm old school, but in my opinion, trunk should only contain
agreed-upon features. It should also always build and pass tests
successfully. It's not the wild-west version of PHP, it's PHP's next
version, in progress. Want to work on something experimental or
controversial? Do that in a branch, merge it if & when it gets
accepted to the language.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php