Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83613
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: <54EB9F0C.6080909@lsces.co.uk>
Date: Mon, 23 Feb 2015 21:43:40 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>	<CAEPJduk3VgWYgpuJ4G0JvUXYaMoO7430Q0k7v5ifwWF_dzh9rA@mail.gmail.com>	<9aec85c81b49009c6238ff6d8be27cd4@mail.gmail.com>	<CAEPJdukoBG3M1q3UqJ9LW-GBqhVB7-ybkdJqiGENN2w10XqEhw@mail.gmail.com>	<f881d1e1bb6026b96498cfd787d3fd0a@mail.gmail.com> <CAEPJdumFJup3mKsaYxi11O0f6L3BAvOUa=Z9tTKy8B01tvu8PQ@mail.gmail.com> <2dcfd9f4a3f0f9bbf2a13f679359e6ea@mail.gmail.com>
In-Reply-To: <2dcfd9f4a3f0f9bbf2a13f679359e6ea@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: lester@lsces.co.uk (Lester Caine)

On 23/02/15 18:09, Zeev Suraski wrote:
> I don't think it will.  But instead of guessing, we should try the patch
> with some real world apps and find out.  I think that if we find out we can
> migrate Drupal (or whatever) in a couple of days or even a couple of weeks
> to be E_DEPRECATED free - this approach is very viable.  If it requires
> months and months of updates, it'll be a different story.

There are still a number of things that need agreement before moving
forward?

1/ The 'strict hint' camp can't see why even if 'disabled' so that we
don't have to bother with it they can have what they want, but it's
another layer of unnecessary code even if it can be optimized out.

2/ Drop the 'strict' but keep STH and we still have another layer of
complexity that may not fit with other methods of handling variable
validation.

3/ Changing the rules for converting types is in my list a separate
question to adding STH at all. Even if STH is not being used the rules
change? At least some alternative means of producing the current style
of working should be retained.

4/ There IS still the alternative option of proper annotation which will
provide an alternate method of including type hinting without needing to
change the run time code at all. I don't see why this is being rejected
as vehemently as not including strict or incorporating annotation IN the
code. Keeping development time information in a separate wrapper both
allows everyone to follow their own preferences and develop validation
tools that work for PHP rather than forcing the use of some other
language that is flavour of the month.

Neither strict, Coercive processing nor François's alternative provide a
complete solution to the validation requirements. Something which could
be provided if the right hooks are available to identify hints be that
the current rules or some third party strict rule set. There was a query
about making hints user definable and that fits in better than any of
the current 'single' solutions? Currently nothing is the perfect
solution so should any be made compulsory?

-- 
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