> On Aug 18, 2020, at 6:54 AM, Benjamin Eberlei <kont...@beberlei.de> wrote:
>
> On Tue, Aug 18, 2020 at 12:36 AM Mike Schinkel <m...@newclarity.net
> <mailto:m...@newclarity.net>> wrote:
> I have been following all the lengthy discussions on this topic hoping the
> list would come to consensus. And I had been hoping someone would call the
> following question but since no one else has here goes.
>
> The concept of adding attributes to PHP seemed to sail to acceptance but, if
> you count the original RFC there have been three (3) different RFCs each with
> the goal of setting or changing the decided syntax alone.
>
> For every syntax proposed there seems to be a contingent of people who are
> deeply troubled by it. Given that once a syntax lands in an official release
> of PHP there are not take backs, moving forward with any syntax where people
> are so divided seems like a really bad idea.
>
> If we care about future developers being happy enough with the decisions made
> about PHP to continue choosing PHP that I would think it would be incumbent
> upon us to find a syntax with a greater level of buy-in.
>
> Should we not:
>
> 1. Postpone inclusion of attributes until PHP 8.1 to ensure that we get a
> syntax that is reasonable acceptable to large segment of stakeholders?
>
> All the technically complex decisions are done, tested and decided. The
> syntax question is still open, but not critical from a technical
> implementation POV. All patches regardless of syntax are extremely similar,
> just replacing symbols. The non-technical implications and future related
> questions are what is up for decision. The arguments for or against these
> categories are by now driving in circles. Postponing to 8.1 does therefore
> not bring additional value. A decision has to be made and we have enough time
> for that.
>
> 2. Optionally have an RFC to ask people to vote on disputed principles, such
> as "Are ending delimiters important and thus are they required for any
> selected syntax?"
>
> By voting for a syntax, these questions are answered implicitly.
Then may I please be allowed to add another option (or two) to the RFC, in
hopes that it will be disliked less by everyone that the level of dislike a set
of people have for every option?
I propose we utilize the "use" command but with required parenthesis using
examples from my code where I previously simulated attributes:
// class attribute use
use PostType('abc_product'),
TemplateVariable('product'),
VirtualReadonly('id'),
VirtualReadonly('name');
// method attribute use
use PrimaryKey();
An option to the above is we utilize the "use" command w/o required parenthesis
but w/attribute modifier, although this is not my preference:
// class attribute use
use attribute PostType('abc_product'),
TemplateVariable('product'),
VirtualReadonly('id'),
VirtualReadonly('name');
// method attribute use
use attribute PrimaryKey;
I have prepared a longer example as a Gist:
https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8
<https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8>
Appropriateness
---------------------
The second option is similar to "use function " so while it is not exactly the
same, "use" is utilized by three contexts already, two (2) of them w/o a
modifier:
1.) providing a local name for a namespace,
2.) providing a local name for a function, and
3.) what is effectively an include() for a trait.
The semantics of "use" works for attributes — i.e. "Use this attribute for the
following declaration" — and having a 4th type of use seems like it would fit
nicely into the existing language.
I would suggest viewing all the different syntaxes to see who "use AttrFunc()"
compares in terms of readability:
https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8
<https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8>
Benefits
-----------
1. Short; three (3) characters that — importantly — DO NOT require use of the
shift key (which my carpal tunnel would be thankful for.).
1a. The 2nd options should be easy to type with an IDE/editor that
supports macros
1b. For example in PhpStorm you could assign ua<tab> to expand to "use
attribute "
2. Has a closing delimiter, the semi-colon.
3. Supports grouping, using commas just like other uses of the "use" command.
4. Forward compatible in PHP 7 (I think.)
5. Uses existing T_USE attribute.
6. (I do not know if it would change the lexing of remaining tokens)
7. Does not prevent the nesting of attributes in the future as braces could be
used as they currently are with traits
-Mike
