Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50444
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Tue, 23 Nov 2010 14:04:37 +0000 (GMT)
To: Zeev Suraski <zeev@zend.com>
cc: Felipe Pena <felipensp@gmail.com>, internals <internals@lists.php.net>
In-Reply-To: <887FE7CFF6F8DE4BB3A9535F53AFD06A2C5B099F@il-ex2.zend.net>
Message-ID: <alpine.DEB.2.00.1011231400010.24401@kossu.derickrethans.nl>
References: <AANLkTi=coWEEMNnr_SsTCo7HaXUPRwcJg7fUz=NjA8nq@mail.gmail.com> <alpine.DEB.2.00.1011230945310.24401@kossu.derickrethans.nl> <887FE7CFF6F8DE4BB3A9535F53AFD06A2C5B099F@il-ex2.zend.net>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: RE: [PHP-DEV] Hold off 5.4
From: derick@php.net (Derick Rethans)

On Tue, 23 Nov 2010, Zeev Suraski wrote:

> On Tue, 23 Nov 2010, Derick Rethans wrote:
> > 
> > On Mon, 22 Nov 2010, Felipe Pena wrote:
> > 
> > > Given the current state of trunk, I think 5.4 release process should
> > > not begin tomorrow (alpha or whatever other status). There are
> > > numerous identified issues that we need to fix before even think to
> > > begin with a release. For example:
> > >
> > > - type hinting (or strict hinting)
> > > - no consensus
> > > - the RFCs are unclear
> > > - BC break introduced
> > > . classes named as any of the type hint scalar types do not work
> > > anymore aka class int {}
> > 
> > Yeah, there is a slight hint of a BC break in case you have a class named "int"
> > or "float" etc. But there is:
> > http://uk.php.net/manual/en/userlandnaming.tips.php
> 
> For the record, I'm still very uncomfortable with this new language 
> syntax - even if it's a no-op right now.

I know you are; but from what I understood, there were no more comments 
to the latest mail (with patch and RFC) that I've made towards this.

I'm not comfortable about not having the proper strict checks that we 
had. It seems we're both having to live with something uncomfortable.

> Are we effectively going to create the original type checking 
> implementation, but in a separate component people would have to 
> install - thereby creating two very different flavors of PHP?

It's clearly a debugging aid for me. So this should be in a debugging 
extension. I doubt any sort of shared hoster would install it, but it 
*does* give people the power to do this for their own controlled set-up. 
Also, if the extension is suddenly not there, the app will still work so 
I am not buying your "two flavours" argument.

> Regarding the alpha release, I think there are two key issues here:
> 
> 1.  Does this alpha mean anything at all.  Some, myself included, 
> don't feel comfortable about the state of certain things in the 
> current codebase (example given above).  Are we all in sync that even 
> if a certain feature makes it into the alpha, it doesn't mean that it 
> won't be removed or be severely modified in an upcoming beta/GA? 
> Is it clear it has no implications on when the final release would be?  
> That is, at least, the way I perceive alpha releases.  In which case 
> it's not exactly clear to me what the benefits of releasing an Alpha 
> in this day and age for PHP - where we have snapshots every few hours.  
> We need to have a very clear understanding of what this does or 
> doesn't mean, and make sure we communicate it properly to the users.

To me this alpha would be a "this is what we're mostly likely going to 
have thing". I wouldn't like to see new major features, engine rework 
being done; but I also think we shouldn't try to remove stuff from it 
unless really necessary.

regards,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug