On 29/04/16 14:51, Rowan Collins wrote:
> Lester Caine wrote on 29/04/2016 14:18:
>> But where will annotations like @range(0,110) fit in the new model?
>> Along with the likes of '@notnull' and similar annotations that are also
>> currently being planned to be spread around the rest of the code? If a
>> variable is defined via the metadata as 'not null', then assigning null
>> to it is an error
>
> Hi Lester,
>
> Do you mean you are currently using these attributes / annotations with
> a reflection library to generate assertions in the code and throw errors
> at runtime? If so, yes, the native syntax will be used for that going
> forward, once the tools catch up (though they're likely to provide
> backwards compatibility modes for a fairly long time).
I think that is part of the problem here. IDE's are currently making
quite good use of existing annotation text, but if they have to be
switched to modes where some other option takes priority then once again
all the code has to be reworked ... which is where I'm stuck at the moment.
> However, there's no support built into the core for doing the actual
> checks now, and there's no plan (that I know of) to build one in in
> future. All that's proposed is to add more support in the language for a
> general syntax which can be used by such tools, to avoid them doing so
> much string parsing.
>
> If you're just using these annotations for documentation (as your
> references to phpDocumentor imply), then nothing will change: you'll
> still be able to use them for that, and they still won't be enforced.
> This is exactly the same as has been true since PHP 5.0 for argument
> types; the engine never validates anything in the docblock, and it might
> be completely wrong, and we have separate syntax for actually enforcing
> checks:
I was looking at php-annotations having realised that it already had
@range which is the bit I'm trying to automate more. Except it doesn’t
... it has stripped the data validation annotations 'because
phpdocumentor2 does not support them'. HENCE asking the question about
this important area here ...
> /**
> * @param Foo $foo
> */
> function test(Bar $bar) {}
>
> Even if there were no other downsides to the syntax, it would probably
> be a bad idea for the core to start enforcing things based on docblocks,
> because it would potentially break a lot of code that had them written
> wrong. Indeed, it is for precisely this reason that a new syntax is
> being proposed for general machine-readable attributes (rather than just
> functions for parsing the docblock), so that we can return to seeing
> docblocks as just comments, with no meaning for the code.
To repeat ... what happens where an IDE has code with both styles of
working? You are exactly right but does adding something extra ACTUALLY
make life easy where we have well documented code and IDE's which
support it.
> In short:
> - if you're generating documentation from docblocks, it's up to the
> program doing the generating what to interpret, and nothing is going to
> change that
> - if you're generating behaviour from docblocks, it's up to the library
> doing the generating what to interpret, and what will change is them
> recommending the new dedicated syntax if it's implemented, because it
> will be more efficient to process
As with 'strict typing' we add different styles of working which in some
longer term world may be an elegant solution but short term just creates
an annoying different way of doing a bit of the job? The current
proposal is offering a fix for a style of working which I still don't
understand, because I can't 'read' easily the examples being given.
<<test("$a + $b > 0")>>
function foo($a, $b) {
}
*I* would expect to be checking the range of $a and $b before adding
some checks combining the data. What is so good about 'test' that adding
an error check inside 'foo' along with the range checks does not
provide? I would expect to ALSO have this limit documented within the
docBloc code anyway as that can include the reason which is absent from
the above example! The comments go hand in hand with the validation so
why not keep them together?
--
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
