Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83563
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <54EB0B7E.3070500@lsces.co.uk>
Date: Mon, 23 Feb 2015 11:14:06 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: 'PHP internals' <internals@lists.php.net>
References: <54EA7BDC.7000002@lsces.co.uk> <06d601d04f13$4b0f2100$e12d6300$@php.net>
In-Reply-To: <06d601d04f13$4b0f2100$e12d6300$@php.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Type hints ...
From: lester@lsces.co.uk (Lester Caine)

On 23/02/15 02:49, François Laupretre wrote:
> Hi Lester,
> 
> I am not sure I understand well, but the extended type syntax partially described in https://wiki.php.net/rfc/dbc may correspond to what you describe. Such extended syntax will be part of 'Design by Contract', meaning it's potentially too slow to run in production and checks can be turned on and off globally. When it is available, PHP argument type hints will become simplified fast checks that run every time, even in production.
> 
> Extended types will support nested syntax as complex as 'object(Iterable)|array('id' => int(]0:), * => string|array(string))'. No limit to the syntax you may support here. It will also be available as a dynamic feature which will allow to check a variable against a dynamically-defined type. *This* will bring dramatic performance improvement in data validation. I don't imagine type hints will bring much in terms of overall performance.
> 
> I guess that's what you mean but please confirm. I think this will be my next project for PHP, after STH if it passes.

My point is simply that 'Type checks performed by STH are faster than
the equivalent PHP code' is only true if ... WHEN COMBINED WITH THE
EXISTING variable validation ... there IS a saving. In my book the type
check is simply part of the range validation so splitting those two does
not make sense. Once I've set up for one check, the other validations
simply follow on. If I ADD further 'magic' checks by using this 'new
feature' it does not do the whole job so I still need the existing
checks anyway.

Reworking 15+ years of code to create 'dbc' versions of the existing
annotations is another drain on available time. I can see someone
writing a 'converter' program to populate some parts of this, but I'm
not sure just how helpful that would be. Just as going through libraries
to see where someone has stripped the docblock and replaced it with the
'new fangled' stuff be that dbc or type hinting. Which is where I would
like existing tools to remain an option, so libraries would need to be
maintained as 'legacy' and 'new' even if we have to maintain those
ourselves :(

>> Currently I have an array of variables and the docblock annotation tells
>> me just what each element is intended to be. I process the variables on
>> that basis and while it may be helpful to have some higher level of
>> 'restraint', I have a working flexible system. As a variable is
>> processed it is constrained by the appropriate rules. If PHP adds 'Type
>> Hints' they will only apply to where I am passing an array variable, and
>> the type hint adds additional processing to that which I already
>> maintain myself. How will that improve performance?
> 
> It won't, except if you remove some redundant checks from your PHP code. Type checks performed by STH are faster than the equivalent PHP code, that's the only possible performance improvement I imagine.
> 
>> Add to this equation that the type and constraints of a variable may
>> well vary from one record set to another. It may well be that a fixed
>> set of types can be defined, but these are not the types currently being
>> defined and would include date types in parallel with a group of numeric
>> types.
>>
>> Passing 'strict' types in some cases just does not compute in my book,
>> and even 'coercive' types only addresses a subset of the types needed so
>> that it adds another layer of 'checking' over what we already have in
>> much of the existing user code base. People keep going on about
>> different rule sets but this just adds another set of 'rules' rather
>> than a single solution.

-- 
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk