Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92944
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <57237B36.1070301@lsces.co.uk>
References: <BY2PR0201MB178479B3AF8BD49583233034BF6E0@BY2PR0201MB1784.namprd02.prod.outlook.com>
	<571E4A83.3080304@garfieldtech.com>
	<571E64A2.2040505@gmail.com>
	<CADqTB_hH4=Rx2ZV_WSJuCPzbnA-ERyFUE8ZsCew2Z6p0+FHWsg@mail.gmail.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>
Date: Fri, 29 Apr 2016 10:01:00 -0600
Message-ID: <CAObuZds7WH25DV3XMSj+g1j-6vg_wFYz_PM16mqyPfeD3=Ucbg@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113d5940c9e0540531a1bf6a
Subject: Re: [PHP-DEV] PHP Attributes -> docBloc alternatives ...
From: derokorian@gmail.com (Ryan Pallas)

--001a113d5940c9e0540531a1bf6a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 29, 2016 at 9:18 AM, Lester Caine <lester@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 al=
so
> >> 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 nul=
l
> >> 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 error=
s
> > 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 momen=
t.
>

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 migh=
t
> > 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=E2=
=80=99t
> ... 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 jus=
t
> > 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=3Dcontact
> 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

--001a113d5940c9e0540531a1bf6a--