On Fri, Apr 29, 2016 at 9:18 AM, Lester Caine <les...@lsces.co.uk> wrote:
> 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.
>
For what reason would you have to rework all the code? Nothing about this
RFC
makes the currently used and working implementations invalid. In fact, I
have a project
written originally in 5.2 that's currently running on 7.0. IIRC, it uses
none of the new
features from 5.4+. I'm still using long hand array syntax (array() vs []),
I'm still using
isset based ternaries (isset($foo)?$foo:'default' vs $foo ?? 'default') and
such things.
However, new code written into this project, since it now runs on 7.0 has
the OPTION
to take advantage of these new features.
>
> > 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 ...
>
I'm not sure I follow, the RFC is suggesting adding annotations that CAN
affect
code if a tool or future RFC is written to provide that feature. Currently,
it only
adds meta-data that can be read more efficiently than using
Refelction*::getDocBlock()
and then string parsing this yourself.
>
> > /**
> > * @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.
>
Currently, my IDE supports every feature that has multiple pathways (both
long
form and short form array works is recognized, mysql_* is still recognized,
even
though its completely removed from php7).
> > 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
>
>
Ryan
