Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92953
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
To: internals@lists.php.net
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <5720A6B4.4000307@lsces.co.uk>
 <CADyq6sKBV0n+xnVhRxsP5RDf0oRLMnNO-BM1VEudRgcK1s199A@mail.gmail.com>
 <CADyq6s+P5p-xdJ8CQaFo3Nrwe7ooyCLg1p=98E0kcSscBbSe8A@mail.gmail.com>
 <CADyq6sJp-krEpGgat7hWm2YpvtfwAfK1ya0as4Tv2qtCSeNgAw@mail.gmail.com>
 <5721B9DD.3050300@lsces.co.uk>
 <CADyq6s+nJoHkMmA+iupA0+7jwJskkdLTe=os=gZDt3dqaJxT7A@mail.gmail.com>
 <57231ADD.9040006@lsces.co.uk>
 <CADyq6s+uELdzWoMd0GBvby205Po_xEpxKoEBkSc_qbxsS3YeXQ@mail.gmail.com>
 <572326A3.7000809@lsces.co.uk>
 <cb7724e7-7436-3013-5a3a-f7df6c35ed86@gmail.com>
 <57234D3D.1070602@lsces.co.uk>
 <79c9df57-ee45-f415-3172-95f8229bbece@gmail.com>
 <CAEPJdunLsPfnE5ebZkcARRO_RR9ni1jWQJg_FW_9XZm9XhpPsQ@mail.gmail.com>
 <57235F20.5080707@lsces.co.uk>
 <43b9c67f-3ec7-bacc-2608-552abbd1a3fa@gmail.com>
 <57237B36.1070301@lsces.co.uk>
 <0d71618b-2ffa-7273-f9b9-aeabc35f4211@gmail.com>
 <572390DC.1020108@lsces.co.uk>
Message-ID: <6b18ff8b-586d-8e97-2e02-ec1db82cefda@gmail.com>
Date: Fri, 29 Apr 2016 18:00:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <572390DC.1020108@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...
From: rowan.collins@gmail.com (Rowan Collins)

Lester Caine wrote on 29/04/2016 17:50:
> On 29/04/16 16:42, Rowan Collins wrote:
>> function foo($a) {
>> if ( $a < 42 ) { throw new Exception; } // Must not reach The Answer
>> ...
>> }
>>
>> vs
>>
>> <<test($a < 42)>> // Must not reach The Answer
>> function foo($a) { ... }
> The first version is my current code base, although it's unlikely to
> throw an exception, more likely to have already validated the data
> before using it so the check is redundant as it is already in the code
> to handle the problem data. But in the second example just where does
> the error redirect traffic? At least with in-line checks you control
> flow ...

A good question. As such, the annotation doesn't execute any code in the 
current proposal, it just allows tools to inspect it, so the answer is 
"anywhere the tool manages to inject the assertion code", I guess.


> but just how do you add a range? Does that need different
> 'test' elements?

<<test>> is just an example. It might be <<Validate\Range(0, 42)>> or 
<<ConstrainType\Int(['min'=>0, 'max'=>42])>> or whatever you / the 
library author wanted it to be. None of this is going to be baked into 
the language.


> My main target here is to add a reliable mechanism to allow every
> variable to have it's own validation attributes. The only current route
> is as php-annotations nicely provided and which dovetails nicely into
> the existing documentation process.

Indeed, the fact that you can add the attributes in advance is a nice 
feature of the annotations-in-docblock syntax. However, the 
disadvantages of that syntax have been discussed elsewhere. Like many 
things in life, it's a tradeoff.

> I've no problem with an alternate annotation method ... as long as in
> PHP7 it is optional ...

Absolutely. Nobody is going to force you to use this syntax, unless you 
want to use some library whose author is really keen on it and doesn't 
provide any other method of doing something.


> but I don't think this 'in-line' approach is
> ACTUALLY the right long term solution to data validation.

You said just now that adding the validation to the docblocks does 
appeal to you. At the end of the day, this is just another syntax for 
doing the same thing; but a more well-defined, easier-to-parse syntax, 
with no baggage of existing usage which it has to be compatible with.

If it's not the right tool for your use case, that's fine too; maybe 
it's the right tool for someone else's use case, though.

Regards,
-- 
Rowan Collins
[IMSoP]