Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49415
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: Thu, 12 Aug 2010 09:31:32 +0100 (BST)
To: Zeev Suraski <zeev@zend.com>
cc: Stas Malyshev <smalyshev@sugarcrm.com>, 
    PHP Internals <internals@lists.php.net>
In-Reply-To: <7.0.1.0.2.20100811214923.1540f9a0@zend.com>
Message-ID: <alpine.DEB.2.00.1008120930130.29410@kossu.derickrethans.nl>
References: <4C62EC4A.9020106@sugarcrm.com> <alpine.DEB.2.00.1008111932580.29410@kossu.derickrethans.nl> <7.0.1.0.2.20100811214923.1540f9a0@zend.com>
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] back to 5.4 alpha
From: derick@php.net (Derick Rethans)

(after clarification on what Zeev meant, there was a bit of a follow up 
that I'm posting as reply):

On Wed, 11 Aug 2010, Zeev Suraski wrote:

> How is it different from having both options?  Given enough time isn't 
> it exactly the same thing? Argument verification should not be a 
> customizable feature.
> 
> Collecting the info (for documentation purposes and reflection) is 
> something else and I think that's fine - and then the only question 
> that remains is the syntax (which IIRC includes modifiers for 
> strict/weak that we should probably clean up).
> 
> If I understood the idea behind the patch, you want to pass on the 
> argument validation function to the engine on startup.  That means 
> that overnight there'll be a version of PHP supporting different 
> validation functions.  Or am I missing something?

Well, PHP wouldn't support it directly. But it would allow a zend 
extension like Xdebug to provide a strict validation function while 
debugging and development. Very similar to the overloaded zend_error_cb 
and var_dump() function. During production you'd obviously *not* have a 
caster/strict type validator. 

It seems quite clear that "you lot" don't like a strict type check; 
whereas another lot don't like a casting typecast. I'd be much for your 
option #3 (no scalar type hint/cast/strict check by default); but still 
allow other tools to access the information that's been supplied by the 
parser. That doesn't even necessarily have to be an argument 
validator/cast/type check of course; but simple introspection tools that 
makes marshalling data to other more type-sensitive data sources. I've 
been working with MongoDB here for the past week, and that'd be such a 
data source.

Derick


> At 21:38 11/08/2010, Derick Rethans wrote:
> > On Wed, 11 Aug 2010, Stas Malyshev wrote:
> > 
> > > So I'd propose doing the following:
> > >
> > > 1. Moving parameter typing to a feature branch (by branching current trunk
> > and
> > > then rolling back the typing part in the trunk).
> > > 2. Starting 5.4 alpha process after that basing on trunk.
> > >
> > > Any objections to this?
> > 
> > A little bit; yes. There is indeed 0 consensus for having the strict
> > typehints. However, instead of removing it altogether, and instead
> > answering every mail in this thread :P, I wrote/am writing a patch that
> > removes the hard type checks. It however keeps the parsed structures and
> > reflection API for it. In this sense, they're actually real hints. The
> > patch also adds a mechanism similariy to the zend_error_cb mechanism so
> > that extensions could override the argument type checking. As my use
> > case for strict checking is development I'd be happy to just move the
> > hard checks into an extension. I could even offer a soft check. It also
> > allows some type inference which might be useful for webservice
> > introspecition generation. I am sure SOAP might have some benefit of
> > this, and I know that at least pecl/dbus does. The patch is attached,
> > but not ready (I haven't remove the hard checks yet because things got
> > busy at work).
> > 
> > Derick
> > 
> > --
> > http://derickrethans.nl | http://xdebug.org
> > Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> > twitter: @derickr and @xdebug
> > 
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> 

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug