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.
Regards
François
> De : Lester Caine [mailto:les...@lsces.co.uk]
>
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
