Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benjamin Eberlei]

On Mon, Jun 1, 2020 at 1:48 AM Theodore Brown 
wrote:

> On Wed, May 20, 2020 at 12:07 PM Benjamin Eberlei 
> wrote:
>
> > the Attributes RFC was rather large already, so a few things were left
> > open or discussions during the vote have made us rethink a things.
> >
> > https://wiki.php.net/rfc/attribute_amendments
> >
> > These points are handled by the Amendments RFC to Attributes:
> >
> > 1. Proposing to add a grouped syntax <
>
> Hi Benjamin,
>
> I find the grouped attribute proposal somewhat troubling. The RFC
> contains the following example:
>
> ```php
> <   Attr2("bar")>>
> public function test()
> {
> }
> ```
>
> The problem with this syntax is that adding a new attribute at the
> start or end of the list, or removing one of the attributes, will
> require modifying multiple lines. For some time the language has been
> moving away from this (see the various RFCs to allow trailing commas
> in more places), so this feels like a step backwards.
>
> If trailing commas are allowed in grouped attributes, you could
> write it this way instead:
>
> ```php
> <<
>   Attr2("foo"),
>   Attr2("bar"),
> >>
> public function test()
> {
> }
> ```
>
> But to me this still feels rather clunky. It requires two extra lines,
> and when moving from two attributes to one attribute (or vice versa),
> you'd still probably end up modifying multiple lines.
>

I have added trailing commas to the attribute grouping. Now that its
possible everywhere, we should go with it here directly from the beginning.

About clunkyness, I am not sure this makes sense as an argument, bceause
the extra lines are present for all other cases of trailing commas in
popular coding styles:

[
"arg1",
"arg2",
]

or

foo(
  "arg1",
  "arg2",
);

>
> Another issue with the grouped syntax is that comma separated
> attributes can be easy to confuse with comma separated attribute
> arguments. For example:
>
> ```php
> <>
> <>
> function bar() {}
> ```
>
> It can be hard to tell which line contains multiple attributes vs.
> multiple attribute arguments.
>

The same is true about commas in nested short arrays.

>
> Ultimately it seems like the grouped attribute proposal is attempting
> to work around the poor usability of the current verbose syntax. Maybe
> it would be better to instead propose a simpler syntax that avoids
> these issues. I know that some internals members expressed interest
> in an `@@` token, but this was never voted on.
>

If you feel strongly about it, please create your own RFC for this. You
would need to put it under discussion within this week though, as the
feature freeze deadlines are looming.

Personally I have no interest in opening up the syntax question again,
because there are really not many objective arguments to be made, its
mostly subjective and feeling based.

>
> Having a distinct token for attributes would entirely avoid the issues
> of having to modify multiple lines when adding/removing attributes, as
> well as confusion with shift operators and comma-separated attribute
> arguments. E.g. the RFC example would look like this instead:
>

@@ is not a distinct token though, because it is already valid syntax to
have the error silence operator multiple times after each other.

>
> ```php
> @@Attr2("foo")
> @@Attr2("bar")
> public function test()
> {
> }
> ```
>
> To me this would be a lot cleaner and fit in better with the rest of
> the language.
>
> Best regards,
> Theodore
>

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Rowan Tommins]

On Mon, 1 Jun 2020 at 00:48, Theodore Brown  wrote:

>
> Having a distinct token for attributes would entirely avoid the issues
> of having to modify multiple lines when adding/removing attributes, as
> well as confusion with shift operators and comma-separated attribute
> arguments. E.g. the RFC example would look like this instead:
>
> ```php
> @@Attr2("foo")
> @@Attr2("bar")
> public function test()
> {
> }
> ```
>


I'm not sure what you mean by "having a distinct token"; the cases where
there is any chance of confusion with bit-shifts are going to be very rare,
and aren't related to any of the other issues you're discussing. You make
some good points about not having comma-separated attributes, but they
don't require us to change the syntax, just not add that feature to it.

On a personal note, I find @@ a lot uglier than << and think a bracket-link
syntax looks clearer when writing multiple attributes on one line to avoid
long thin columns of code:

<> <>
public function test()
{
}

vs

@@Attr2("foo") @@Attr2("bar")
public function test()
{
}

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Theodore Brown]

On Wed, May 20, 2020 at 12:07 PM Benjamin Eberlei  wrote:

> the Attributes RFC was rather large already, so a few things were left
> open or discussions during the vote have made us rethink a things.
>
> https://wiki.php.net/rfc/attribute_amendments
>
> These points are handled by the Amendments RFC to Attributes:
>
> 1. Proposing to add a grouped syntax <

Hi Benjamin,

I find the grouped attribute proposal somewhat troubling. The RFC
contains the following example:

```php
<>
public function test()
{
}
```

The problem with this syntax is that adding a new attribute at the 
start or end of the list, or removing one of the attributes, will
require modifying multiple lines. For some time the language has been
moving away from this (see the various RFCs to allow trailing commas
in more places), so this feels like a step backwards.

If trailing commas are allowed in grouped attributes, you could
write it this way instead:

```php
<<
  Attr2("foo"),
  Attr2("bar"),
>>
public function test()
{
}
```

But to me this still feels rather clunky. It requires two extra lines, 
and when moving from two attributes to one attribute (or vice versa),
you'd still probably end up modifying multiple lines.

Another issue with the grouped syntax is that comma separated
attributes can be easy to confuse with comma separated attribute 
arguments. For example:

```php
<>
<>
function bar() {}
```

It can be hard to tell which line contains multiple attributes vs.
multiple attribute arguments.

Ultimately it seems like the grouped attribute proposal is attempting
to work around the poor usability of the current verbose syntax. Maybe
it would be better to instead propose a simpler syntax that avoids
these issues. I know that some internals members expressed interest
in an `@@` token, but this was never voted on.

Having a distinct token for attributes would entirely avoid the issues
of having to modify multiple lines when adding/removing attributes, as
well as confusion with shift operators and comma-separated attribute
arguments. E.g. the RFC example would look like this instead:

```php
@@Attr2("foo")
@@Attr2("bar")
public function test()
{
}
```

To me this would be a lot cleaner and fit in better with the rest of
the language.

Best regards,
Theodore

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benjamin Eberlei]

On Thu, May 28, 2020 at 12:05 AM Benas IML 
wrote:

> It seems that the RFC was updated to use the `Attributes` namespace. I
> think this is a bad idea since we're reserving a generic namespace that we
> haven't even "soft" reserved. Also, the loss of fallback to global
> namespace is a turning point for me.
>
> Generally, I think we should instead do something like Rowan said: use
> namespaced classes only for implementations (e.g. `\Attribute` but
> `\PHP\Deprecated`).
>

I agree on sentiment, but the PHP namespace vote is failing right now, so
that makes this plan just a rehashing of the existing, failing vote.

The likelihood of a class Attributes\Attribute or Attributes\Deprecated
existing in any code out there is much much lower, than the classes
Attribute and Deprecated existing in the global namespace. The "PHP\"
namespace would imply some sort of claim of the project, which the failing
namespace vote shows does not exist.

The way attributes map to classes, suffixes/prefixes make them strange to
look at, so for future non-breaks with userland code it will be safer to
put them off to a new namespace and this potentially increases the user
perception.

If this vote fails, this implicitly means that all future internal
attributes will probably go into the global namespace.

>
> Best regards,
> Benas
>
> On Wed, May 20, 2020, 8:08 PM Benjamin Eberlei 
> wrote:
>
>> Hi everyone,
>>
>> the Attributes RFC was rather large already, so a few things were left
>> open
>> or discussions during the vote have made us rethink a things.
>>
>> https://wiki.php.net/rfc/attribute_amendments
>>
>> These points are handled by the Amendments RFC to Attributes:
>>
>> 1. Proposing to add a grouped syntax <
>> 2. Rename PhpAttribute to Attribute in global namespace (independent of
>> the
>> namespace RFC)
>> 3. Add validation of attribute class targets, which internal attributes
>> can
>> do, but userland can't
>> 4. Specification if an attribute is repeatable or not on the same
>> declaration and fail otherwise.
>>
>> Each of them is a rather small issue, so I hope its ok to aggregate all
>> four of them in a single RFC. Please let me know if it's not.
>>
>> greetings
>> Benjamin
>>
>

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benas IML]

It seems that the RFC was updated to use the `Attributes` namespace. I
think this is a bad idea since we're reserving a generic namespace that we
haven't even "soft" reserved. Also, the loss of fallback to global
namespace is a turning point for me.

Generally, I think we should instead do something like Rowan said: use
namespaced classes only for implementations (e.g. `\Attribute` but
`\PHP\Deprecated`).

Best regards,
Benas

On Wed, May 20, 2020, 8:08 PM Benjamin Eberlei  wrote:

> Hi everyone,
>
> the Attributes RFC was rather large already, so a few things were left open
> or discussions during the vote have made us rethink a things.
>
> https://wiki.php.net/rfc/attribute_amendments
>
> These points are handled by the Amendments RFC to Attributes:
>
> 1. Proposing to add a grouped syntax <
> 2. Rename PhpAttribute to Attribute in global namespace (independent of the
> namespace RFC)
> 3. Add validation of attribute class targets, which internal attributes can
> do, but userland can't
> 4. Specification if an attribute is repeatable or not on the same
> declaration and fail otherwise.
>
> Each of them is a rather small issue, so I hope its ok to aggregate all
> four of them in a single RFC. Please let me know if it's not.
>
> greetings
> Benjamin
>

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benas IML]

That's a brilliant idea, completely agreed, Rowan!

On the other note, don't want to nitpick here but I believe that it would be
better to name the repeatable attribute simply as `<>`. It would
match other languages (such as Java) and the naming wouldn't be that
verbose.

Also IMO, I think for consistency we should either use only parameters e. g.
`<>` or separate
attributes for both target validation and repeatability e. g.
`<>`  and `<>`.

Best regards,
Benas Seliuginas

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Rowan Tommins]

On 22/05/2020 12:08, Nikita Popov wrote:

As such, I would suggest to introduce a common namespace for all attributes
provided by PHP. This means we'd have Attributes\Attribute,
Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay
with the PHP\Attributes\Deprecated variant, but that's a separate question).



One possible policy which came up in chat last night was that universal 
base classes (which tend to be few in number, and act almost as 
keywords) should be in the root namespace; but built-in implementations 
of those (at the same level as ones users could create) are prefixed 
with "PHP\Something\".


For instance, if we had a time machine and were adding them all now:

- "\Throwable" and "\Exception", but "\PHP\Exceptions\RuntimeException"
- "\Iterator" but "\PHP\Iterators\FilterIterator"
- "\Attribute", but "\PHP\Attributes\Deprecated"

Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Bob Weinand]

> Am 22.05.2020 um 13:08 schrieb Nikita Popov :
> 
> On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei 
> wrote:
> 
>> 2. Rename PhpAttribute to Attribute in global namespace (independent of the
>> namespace RFC)
> 
> As was mentioned in one of the previous discussions, we expect that PHP is
> going to ship more language-provided attributes in the future. With this
> proposal we have the "Attribute" attribute, but I expect we'll at least
> have "Deprecated" as well, and probably also something along the lines of
> "Jit" or "NoJit". While I'm happy with "Attribute" living in the global
> namespace, I don't really think we'd want to introduce "Jit" as a class in
> the global namespace. The name is simply to generic and does not indicate
> that this is part of the attribute system. We'd be forced to go with things
> like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to
> me, as we're just reinventing namespaces to avoid using them...
> 
> As such, I would suggest to introduce a common namespace for all attributes
> provided by PHP. This means we'd have Attributes\Attribute,
> Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay
> with the PHP\Attributes\Deprecated variant, but that's a separate question).
> 
> Nikita

At that point, don't we just want to be able to generically mark all attribute 
classes visible as being an Attribute?

Also the classical examples like <> do not tell you anyhow 
that they're Attributes, if the class is accessed outside of attribute context. 
And I guess, with the logic you proposed, it will likely be named 
"ORM\Attribute\Entity" making it even longer.

I think it would be good to be able to later on just write <>, 
<> etc. without further imports, as they seem to be quite basic 
functionality. I think it should remain possible to write simple code without 
much namespace awareness.

Perhaps we should actually name attribute classes including their << and >>. 
Thus "class <> {}" (attribute decl), "new <>()" (custom 
instantiation), "$attribute instanceof <>". (and, for a namespaced 
attribute "$attribute instanceof MyNamespace\<>")
The engine could quite easily support that, it's just a little parser work.

That way the whole discussion as to where to put attributes in the namespace 
hierarchy would be quite moot, for PHP itself as well as userland.

Bob

P.s.: As a caveat, on parameter types, if we expect a value being of an 
attribute class, we'd need to require a qualified name containing at least one 
backslash or import-alias there. But that's acceptable I think, it will just 
happen within some internal attribute processing code.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Jakob Givoni]

On Fri, May 22, 2020 at 5:28 PM Nikita Popov  wrote:
>
> I don't particularly care what namespace the attribute classes are under,
> just that they should have a common namespace, because there's going to be
> many of them, presumably. If it was just a matter of the Attribute class,
> I'd definitely say this belongs in the global namespace, but that's not
> what we're dealing with at this point.
>

You've made a really good argument for the \Php namespace here.
I get that PHP reserves the global namespace, but I'm pretty certain
that if PHP ever needs any subspaces, they should be under a common,
non-global, namespace.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Nikita Popov]

On Fri, May 22, 2020 at 5:29 PM Benjamin Eberlei 
wrote:

>
>
> On Fri, May 22, 2020 at 1:08 PM Nikita Popov  wrote:
>
>> On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> the Attributes RFC was rather large already, so a few things were left
>>> open
>>> or discussions during the vote have made us rethink a things.
>>>
>>> https://wiki.php.net/rfc/attribute_amendments
>>>
>>> These points are handled by the Amendments RFC to Attributes:
>>>
>>> 1. Proposing to add a grouped syntax <
>>
>> 2. Rename PhpAttribute to Attribute in global namespace (independent of
>>> the
>>> namespace RFC)
>>>
>>
>> As was mentioned in one of the previous discussions, we expect that PHP
>> is going to ship more language-provided attributes in the future. With this
>> proposal we have the "Attribute" attribute, but I expect we'll at least
>> have "Deprecated" as well, and probably also something along the lines of
>> "Jit" or "NoJit". While I'm happy with "Attribute" living in the global
>> namespace, I don't really think we'd want to introduce "Jit" as a class in
>> the global namespace. The name is simply to generic and does not indicate
>> that this is part of the attribute system. We'd be forced to go with things
>> like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to
>> me, as we're just reinventing namespaces to avoid using them...
>>
>> As such, I would suggest to introduce a common namespace for all
>> attributes provided by PHP. This means we'd have Attributes\Attribute,
>> Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay
>> with the PHP\Attributes\Deprecated variant, but that's a separate question).
>>
>
> Deprecated would be an "engine level" feature, but Opcache is an
> extension, so it can have its own namespace "Opcache\Jit". The namespace
> RFC goes that far mentioning only " core symbols which cannot be unbundled"
> should go into a PHP namespace, which would exclude Opcache (and its
> "sub-extension" JIT). https://wiki.php.net/rfc/php-namespace-in-core
>
> So for me that is not necessarily an argument against Attribute in global
> NS, because Jit would live in Opcache\.
>

Interesting point. I think this is more an argument against using a "PHP"
vendor namespace, than against using an "Attributes" namespace. JIT is not
"really" an opcache feature, it just lives in opcache right now because it
happens to be convenient. There are long term plans to move the
optimization-related functionality from opcode into core, and JIT should
also live in core (and I think there are plenty of workloads that are
interested in JIT without the SHM caching). Given that context, calling the
attribute Opcache\Jit seems somewhat ill-advised. I also think we'd want to
provide this attribute independently of whether opcache is actually loaded,
because annotating functions with it would be rather problematic if it's
not always available...

Ultimately I'm okay with going with just "Attribute" here, but we need to
acknowledge that this comes with future obligations. In particular,
introducing a "Deprecated" class is a "no" from me, because the name is too
generic and does not indicate that this is part of the attribute system. It
will need to be "DeprecatedAttribute" (or "Attribute_Deprecated", ugh).
Which also means that you need to "use DeprecatedAttribute as Deprecated"
to use it. This isn't terrible, but I also don't think it's ideal.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benjamin Eberlei]

On Fri, May 22, 2020 at 1:08 PM Nikita Popov  wrote:

> On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei 
> wrote:
>
>> Hi everyone,
>>
>> the Attributes RFC was rather large already, so a few things were left
>> open
>> or discussions during the vote have made us rethink a things.
>>
>> https://wiki.php.net/rfc/attribute_amendments
>>
>> These points are handled by the Amendments RFC to Attributes:
>>
>> 1. Proposing to add a grouped syntax <
>
> 2. Rename PhpAttribute to Attribute in global namespace (independent of the
>> namespace RFC)
>>
>
> As was mentioned in one of the previous discussions, we expect that PHP is
> going to ship more language-provided attributes in the future. With this
> proposal we have the "Attribute" attribute, but I expect we'll at least
> have "Deprecated" as well, and probably also something along the lines of
> "Jit" or "NoJit". While I'm happy with "Attribute" living in the global
> namespace, I don't really think we'd want to introduce "Jit" as a class in
> the global namespace. The name is simply to generic and does not indicate
> that this is part of the attribute system. We'd be forced to go with things
> like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to
> me, as we're just reinventing namespaces to avoid using them...
>
> As such, I would suggest to introduce a common namespace for all
> attributes provided by PHP. This means we'd have Attributes\Attribute,
> Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay
> with the PHP\Attributes\Deprecated variant, but that's a separate question).
>

Deprecated would be an "engine level" feature, but Opcache is an extension,
so it can have its own namespace "Opcache\Jit". The namespace RFC goes that
far mentioning only " core symbols which cannot be unbundled" should go
into a PHP namespace, which would exclude Opcache (and its "sub-extension"
JIT). https://wiki.php.net/rfc/php-namespace-in-core

So for me that is not necessarily an argument against Attribute in global
NS, because Jit would live in Opcache\.

>
> Nikita
>
> 3. Add validation of attribute class targets, which internal attributes can
>> do, but userland can't
>> 4. Specification if an attribute is repeatable or not on the same
>> declaration and fail otherwise.
>>
>> Each of them is a rather small issue, so I hope its ok to aggregate all
>> four of them in a single RFC. Please let me know if it's not.
>>
>> greetings
>> Benjamin
>>
>

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Nikita Popov]

On Fri, May 22, 2020 at 2:19 PM Benas IML  wrote:

> Agreed.
>
> I don't think we should pollute any other than the `PHP\` namespace. If
> that RFC doesn't pass though, we should keep the `Attribute` class in the
> global namespace.
>
> Global namespace is already reserved for PHP and so, BC breaks aren't that
> severe whereas `Attributes\` namespace isn't reserved therefore BC breaks
> would be "unexpected".
>
> Best regards,
> Benas Seliuginas
>

I mean, realistically speaking, BC breaks with Attributes\Attribute are a
lot less likely than with just Attribute, regardless of what we reserve or
don't. Some pragmatism, please.

I don't particularly care what namespace the attribute classes are under,
just that they should have a common namespace, because there's going to be
many of them, presumably. If it was just a matter of the Attribute class,
I'd definitely say this belongs in the global namespace, but that's not
what we're dealing with at this point.

Nikita

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benas IML]

Agreed.

I don't think we should pollute any other than the `PHP\` namespace. If
that RFC doesn't pass though, we should keep the `Attribute` class in the
global namespace.

Global namespace is already reserved for PHP and so, BC breaks aren't that
severe whereas `Attributes\` namespace isn't reserved therefore BC breaks
would be "unexpected".

Best regards,
Benas Seliuginas

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Peter Bowyer]

On Fri, 22 May 2020 at 12:09, Nikita Popov  wrote:

> While I'm happy with "Attribute" living in the global
> namespace, I don't really think we'd want to introduce "Jit" as a class in
> the global namespace. The name is simply to generic and does not indicate
> that this is part of the attribute system. We'd be forced to go with things
> like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to
> me, as we're just reinventing namespaces to avoid using them...
>
> As such, I would suggest to introduce a common namespace for all attributes
> provided by PHP. This means we'd have Attributes\Attribute,
> Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay
> with the PHP\Attributes\Deprecated variant, but that's a separate
> question).
>

This is the best real-world argument in favour of PHP namespace in core
that I've heard.
https://wiki.php.net/rfc/php-namespace-in-core

If we don't want to introduce classes in the global namespace, it makes
sense to have a reserved PHP namespace we use.

Peter

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Nikita Popov]

On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei 
wrote:

> Hi everyone,
>
> the Attributes RFC was rather large already, so a few things were left open
> or discussions during the vote have made us rethink a things.
>
> https://wiki.php.net/rfc/attribute_amendments
>
> These points are handled by the Amendments RFC to Attributes:
>
> 1. Proposing to add a grouped syntax <

2. Rename PhpAttribute to Attribute in global namespace (independent of the
> namespace RFC)
>

As was mentioned in one of the previous discussions, we expect that PHP is
going to ship more language-provided attributes in the future. With this
proposal we have the "Attribute" attribute, but I expect we'll at least
have "Deprecated" as well, and probably also something along the lines of
"Jit" or "NoJit". While I'm happy with "Attribute" living in the global
namespace, I don't really think we'd want to introduce "Jit" as a class in
the global namespace. The name is simply to generic and does not indicate
that this is part of the attribute system. We'd be forced to go with things
like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to
me, as we're just reinventing namespaces to avoid using them...

As such, I would suggest to introduce a common namespace for all attributes
provided by PHP. This means we'd have Attributes\Attribute,
Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay
with the PHP\Attributes\Deprecated variant, but that's a separate question).

Nikita

3. Add validation of attribute class targets, which internal attributes can
> do, but userland can't
> 4. Specification if an attribute is repeatable or not on the same
> declaration and fail otherwise.
>
> Each of them is a rather small issue, so I hope its ok to aggregate all
> four of them in a single RFC. Please let me know if it's not.
>
> greetings
> Benjamin
>

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Ben Ramsey]

> On May 21, 2020, at 01:06, CHU Zhaowei  wrote:
> 
> It's good to hear that `PhpCompikerAttribute` can be merged, could you 
> include it in the RFC as well? Thus I think people who support 
> `UserlandAttribute` can agree with `Attribute` now as well.


I think I’m the only one who supports `UserlandAttribute`. :-)

Yes, if these two are merged, then naming it `Attribute` is okay with me, since 
there won’t be any confusion with the names and naming schemes.

Cheers,
Ben



signature.asc
Description: Message signed with OpenPGP

RE: [PHP-DEV] [RFC] Amendments to Attributes

[CHU Zhaowei]

Hi Benjamin,

It's good to hear that `PhpCompikerAttribute` can be merged, could you include 
it in the RFC as well? Thus I think people who support `UserlandAttribute` can 
agree with `Attribute` now as well.

Regards,
CHU Zhaowei

-Original Message-
From: Benjamin Eberlei  
Sent: Thursday, May 21, 2020 6:13 AM
To: Ben Ramsey 
Cc: PHP Internals 
Subject: Re: [PHP-DEV] [RFC] Amendments to Attributes

On Wed, May 20, 2020 at 7:53 PM Ben Ramsey  wrote:

> > On May 20, 2020, at 12:07, Benjamin Eberlei  wrote:
> >
> > 2. Rename PhpAttribute to Attribute in global namespace (independent 
> > of
> the
> > namespace RFC)
>
>
> I suggested in a previous thread that we consider renaming 
> `PhpAttribute` to `UserlandAttribute`, since this is the intent of the 
> attribute, and it helps distinguish it from `CompilerAttribute`.
>
> I noticed that the compiler attribute is actually named 
> `PhpCompilerAttribute`, so unless we change its name to 
> `CompilerAttribute`, I don’t think it makes sense to change 
> `PhpAttribute` to `Attribute`. Perhaps we change it to 
> `PhpUserlandAttribute`, for clarity?
>

Ah that's a good point that still needs to be clarified. We realized that 
PhpAttribute and PhpCompilerAttribute should be merged, because the difference 
doesn't make a difference to userland code and it complicates things. For 
example enforcing that PhpCompilerAttribute is just on internal classes would 
not work for generated stub code in Phan/Psalm and so on that "describe" 
internal code by imitating it in userland. This would not be allowed by the 
current implementation and lead to a compiler error, lets say if we imitated 
Deprecated for documentation purposes:

>
class Deprecated {}

This file could not be compiled by current implementation as an error would 
prevent Userland Deprecated class from using PhpCompilerAttribute.

>
> Cheers,
> Ben
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benjamin Eberlei]

On Wed, May 20, 2020 at 7:53 PM Ben Ramsey  wrote:

> > On May 20, 2020, at 12:07, Benjamin Eberlei  wrote:
> >
> > 2. Rename PhpAttribute to Attribute in global namespace (independent of
> the
> > namespace RFC)
>
>
> I suggested in a previous thread that we consider renaming `PhpAttribute`
> to `UserlandAttribute`, since this is the intent of the attribute, and it
> helps distinguish it from `CompilerAttribute`.
>
> I noticed that the compiler attribute is actually named
> `PhpCompilerAttribute`, so unless we change its name to
> `CompilerAttribute`, I don’t think it makes sense to change `PhpAttribute`
> to `Attribute`. Perhaps we change it to `PhpUserlandAttribute`, for clarity?
>

Ah that's a good point that still needs to be clarified. We realized that
PhpAttribute and PhpCompilerAttribute should be merged, because the
difference doesn't make a difference to userland code and it complicates
things. For example enforcing that PhpCompilerAttribute is just on internal
classes would not work for generated stub code in Phan/Psalm and so on that
"describe" internal code by imitating it in userland. This would not be
allowed by the current implementation and lead to a compiler error, lets
say if we imitated Deprecated for documentation purposes:

>
class Deprecated {}

This file could not be compiled by current implementation as an error would
prevent Userland Deprecated class from using PhpCompilerAttribute.

>
> Cheers,
> Ben
>

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benas IML]

Hello,

Would it possible to make a separate RFC for renaming `PhpAttribute` to
`Attribute` and `PhpCompilerAttribute` to `CompilerAttribute`? Since it
would a huge BC break changing this in PHP 8.1.

Best regards,
Benas Seliuginas

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benjamin Eberlei]

On Wed, May 20, 2020 at 7:37 PM Marco Pivetta  wrote:

> Hey Benjamin,
> 
>
>
> On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei 
> wrote:
>
>> Hi everyone,
>>
>> the Attributes RFC was rather large already, so a few things were left
>> open
>> or discussions during the vote have made us rethink a things.
>>
>> https://wiki.php.net/rfc/attribute_amendments
>>
>> These points are handled by the Amendments RFC to Attributes:
>>
>> 1. Proposing to add a grouped syntax <
>> 2. Rename PhpAttribute to Attribute in global namespace (independent of
>> the
>> namespace RFC)
>> 3. Add validation of attribute class targets, which internal attributes
>> can
>> do, but userland can't
>> 4. Specification if an attribute is repeatable or not on the same
>> declaration and fail otherwise.
>>
>> Each of them is a rather small issue, so I hope its ok to aggregate all
>> four of them in a single RFC. Please let me know if it's not.
>>
>
>
> Do you hope to get nested attributes to 8.0, or is it something you'd
> prefer to happen at a later time?
>

Martin evaluated the technical requirements in more detail and we discussed
with others that the timeframe is probably to short to get all the details
fleshed out :-( So we are going to table that for 8.1

>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Benas IML]

Hey,

I personally think that `UserlandAttribute` is too verbose and a quite
useless change since just using `Attribute` will make little to no BC
compatibility breaks (we know that thanks to Rowan, please check out
Renaming PhpAttribute thread) and would also sound more natural. This would
also mean that we would rename `PhpCompilerAttribute` to simply
`CompilerAttribute`.


Best regards,
Benas Seliuginas

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Ben Ramsey]

> On May 20, 2020, at 12:07, Benjamin Eberlei  wrote:
> 
> 2. Rename PhpAttribute to Attribute in global namespace (independent of the
> namespace RFC)


I suggested in a previous thread that we consider renaming `PhpAttribute` to 
`UserlandAttribute`, since this is the intent of the attribute, and it helps 
distinguish it from `CompilerAttribute`.

I noticed that the compiler attribute is actually named `PhpCompilerAttribute`, 
so unless we change its name to `CompilerAttribute`, I don’t think it makes 
sense to change `PhpAttribute` to `Attribute`. Perhaps we change it to 
`PhpUserlandAttribute`, for clarity?

Cheers,
Ben


signature.asc
Description: Message signed with OpenPGP

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Larry Garfield]

On Wed, May 20, 2020, at 12:07 PM, Benjamin Eberlei wrote:
> Hi everyone,
> 
> the Attributes RFC was rather large already, so a few things were left open
> or discussions during the vote have made us rethink a things.
> 
> https://wiki.php.net/rfc/attribute_amendments
> 
> These points are handled by the Amendments RFC to Attributes:
> 
> 1. Proposing to add a grouped syntax <

I'm torn here.  I can absolutely see the use cases for it, but it also is a can 
of worms in terms of many different coding styles.  In short, this is going to 
make more work for FIG to sort out.

> 2. Rename PhpAttribute to Attribute in global namespace (independent of the
> namespace RFC)

I don't feel strongly enough in any direction to bother wading into this... :-)

> 3. Add validation of attribute class targets, which internal attributes can
> do, but userland can't
> 4. Specification if an attribute is repeatable or not on the same
> declaration and fail otherwise.

It's not clear from the RFC what the failure mode is.  If I put an attribute in 
the wrong place, or repeat it when I shouldn't... at what point does the code 
blow up and how?  Does it get silently skipped somewhere?  Is there an 
exception?  Is it purely informational for the user processing it?

The RFC needs to be clearer on what happens when validation fails.  Even if 
that's repeating something from the original RFC, it needs to be clarified here 
so that we know what we're talking about.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Marco Pivetta]

Hey Benjamin,



On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei 
wrote:

> Hi everyone,
>
> the Attributes RFC was rather large already, so a few things were left open
> or discussions during the vote have made us rethink a things.
>
> https://wiki.php.net/rfc/attribute_amendments
>
> These points are handled by the Amendments RFC to Attributes:
>
> 1. Proposing to add a grouped syntax <
> 2. Rename PhpAttribute to Attribute in global namespace (independent of the
> namespace RFC)
> 3. Add validation of attribute class targets, which internal attributes can
> do, but userland can't
> 4. Specification if an attribute is repeatable or not on the same
> declaration and fail otherwise.
>
> Each of them is a rather small issue, so I hope its ok to aggregate all
> four of them in a single RFC. Please let me know if it's not.
>


Do you hope to get nested attributes to 8.0, or is it something you'd
prefer to happen at a later time?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/