Hi Andreas,
On 19/08/2020 11:01, Andreas Leathley wrote:
> I mentioned the benefits of @{} in an email to this list on Monday, with
> the proposal to have both @@ and @{} as attribute syntax, so both camps
> could have their syntax (one with delimiters, one without) with minimal
Please, one and
On Wed, 19 Aug 2020 at 09:46, Jordi Boggiano wrote:
> Just to mention something here in a bit more depth because it is easy to
> overlook in the RFC if you have looked at it a lot.
>
> In "Potential Future Benefits of Enclosed Delimiter Syntax" there is an
> addition of an example using an
On 19.08.20 11:12, Benjamin Eberlei wrote:
With the choice being @@ or @{} - nothing would stop someone (not me ;-))
to make an RFC for 8.1 or later proposing to add a second syntax.
Sure. If @@ would end up winning again (who knows at this point), at
least one positive thing is that @{} could
On Wed, Aug 19, 2020 at 11:13 AM Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:
> Please add discussion about merge conflicts. Any inline grouped
> attribute syntax needs a manual conflict resolution.
>
> With ungrouped syntax, I expect recommended CS to be one attribute per
> line.
>
On Wed, Aug 19, 2020 at 11:01 AM Andreas Leathley
wrote:
> On 19.08.20 10:47, Benjamin Eberlei wrote:
> > One last change that I didn't see yesterday as it was on Github and not
> > this list is the addition of another syntax proposal @{} with the same
> > benefits as @[], a little more
Please add discussion about merge conflicts. Any inline grouped
attribute syntax needs a manual conflict resolution.
With ungrouped syntax, I expect recommended CS to be one attribute per
line.
If this should be the case also for grouped syntax, then it not +1
character, but +2 new lines
On 19.08.20 10:47, Benjamin Eberlei wrote:
One last change that I didn't see yesterday as it was on Github and not
this list is the addition of another syntax proposal @{} with the same
benefits as @[], a little more snowflake than compared to other languages,
but without the BC Break.
I
On Tue, Aug 18, 2020 at 8:00 PM Benjamin Eberlei
wrote:
>
>
> On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote:
>
>> Hi,
>>
>> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
>> Syntax Change RFC to reflect that process:
>>
>>
Hi,
On 18/08/2020 20:00, Benjamin Eberlei wrote:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
I have updated the RFC one last time with as much of the feedback as
possible:
- a section about comparing to complexity of type definitions
- removal of the machine reading section as
On Wed, Aug 19, 2020 at 12:03 AM Theodore Brown
wrote:
> On Tue, Aug 18, 2020 at 1:00 PM Benjamin Eberlei
> wrote:
>
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> >
> > I have updated the RFC one last time with as much of the feedback
> > as possible:
> >
> > - a section about
On Tue, Aug 18, 2020 at 1:00 PM Benjamin Eberlei wrote:
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> I have updated the RFC one last time with as much of the feedback
> as possible:
>
> - a section about comparing to complexity of type definitions
> - removal of the machine
On Tue, Aug 18, 2020 at 12:04 AM Benas IML wrote:
>
>>
>> From the updated RFC:
>>
>> > There are multiple reasons why we believe the previous vote should be
>> > revisited:
>>
>> Ok, bring it on!
>>
>> > At the point of the vote for @@, it was not clear that the syntax required
>> > the
On Tue, Aug 18, 2020, 1:42 AM Andreas Leathley wrote:
> On 18.08.20 00:03, Benas IML wrote:
> > And then boo-yah, 6 months later we want to implement a cool new
> > feature to
> > attributes (a lot of examples were said before, ain't repeating myself)
> but
> > we can't :(( because there is no
On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote:
> Hi,
>
> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> Syntax Change RFC to reflect that process:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Patches and comments welcome.
>
> FWIW, this has an
Hi Benjamin,
## Easier machine parsing?
The RFC shows a list of different ways that attributes with the `@@`
syntax can end, and claims "This makes programmatic token based
scanning for attribute syntax without a closing delimiter such as `@@`
unnecessarily complicated."
But I've worked with
On 18.08.20 00:03, Benas IML wrote:
And then boo-yah, 6 months later we want to implement a cool new
feature to
attributes (a lot of examples were said before, ain't repeating myself) but
we can't :(( because there is no ending delimiter and thus, we will run
into parsing issues.
Both @{} and
On Tue, Aug 18, 2020, 12:56 AM Jakob Givoni wrote:
> On Sun, Aug 16, 2020 at 11:36 AM Benjamin Eberlei
> wrote:
> >
> > We have updated the RFC with all (hopefully) of the feedback from this
> > discussion:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> >
> > Most notable
On Sun, Aug 16, 2020 at 11:36 AM Benjamin Eberlei wrote:
>
> We have updated the RFC with all (hopefully) of the feedback from this
> discussion:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Most notable changes are:
> - A new section with several subsections on the benefits
On Mon, Aug 17, 2020 at 10:21 AM Benjamin Eberlei wrote:
> On Mon, Aug 17, 2020 at 5:14 PM Theodore Brown wrote:
> > On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown wrote:
> > > On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei wrote:
> > > > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown wrote:
>
On Mon, Aug 17, 2020, at 7:30 AM, Michael Voříšek - ČVUT FEL wrote:
> > possibility to keep @@ and add @{} as a second syntax for attributes
>
> +1, but I would keep same prefix, ie. @@{} (or @@[]), for both syntaxes,
> it is much easier for human eyes to search for one thing, also easier
> for
On Mon, Aug 17, 2020 at 5:
14 PM Theodore Brown wrote:
> On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown
> wrote:
>
> > On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei
> wrote:
> > > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown
> wrote:
> > > > ## Potential Future Benefits of Enclosed
On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown wrote:
> On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei wrote:
> > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown
> > wrote:
> > > ## Potential Future Benefits of Enclosed Delimiter Syntax?
> > >
> > > The RFC shows an example of a potential
On Mon, Aug 17, 2020, 4:07 PM Theodore Brown wrote:
> On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei
> wrote:
>
> > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown
> wrote:
> > > However, ending delimiters in PHP have little to do with how "complex"
> > > a syntax construct is (which is a
On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei wrote:
> On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown wrote:
> > However, ending delimiters in PHP have little to do with how "complex"
> > a syntax construct is (which is a rather loose definition, anyway).
> > As I've pointed out before,
possibility to keep @@ and add @{} as a second syntax for attributes
+1, but I would keep same prefix, ie. @@{} (or @@[]), for both syntaxes,
it is much easier for human eyes to search for one thing, also easier
for grep
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
On Sun, Aug 16, 2020 at 4:47 PM tyson andre
wrote:
> Hi Benjamin,
>
> > We are looking for further feedback from the community.
>
> Thanks, the updated RFC looks much better.
> Some more feedback on why the edge cases are a concern to me,
> and why the lack of an ending delimiter is similar to
On Mon, Aug 17, 2020 at 10:59 AM Alexandru Pătrănescu
wrote:
> On Sun, Aug 16, 2020 at 12:36 PM Benjamin Eberlei
> wrote:
> >
> > We have updated the RFC with all (hopefully) of the feedback from this
> > discussion:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> >
> > Most
On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown
wrote:
> On Sun, Aug 16, 2020 at 4:36 AM Benjamin Eberlei
> wrote:
>
> > We have updated the RFC with all (hopefully) of the feedback from
> > this discussion:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> >
> > Most notable
As a possible addition/discussion point, I only noticed today that @{}
is a syntax that has not been mentioned yet, also not in any previous
discussions about attributes as far as I can tell. @{} currently leads
to a syntax error, so there is no BC break, and {} is common syntax for
grouping
On Sun, Aug 16, 2020 at 12:36 PM Benjamin Eberlei wrote:
>
> We have updated the RFC with all (hopefully) of the feedback from this
> discussion:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Most notable changes are:
> - A new section with several subsections on the benefits
On Mon, 17 Aug 2020 at 02:06, Theodore Brown wrote:
> ## Forcing @@ attributes to end with parenthesis?
>
> I don't really see the point of this section in the RFC.
The blame for that is on me, not Benjamin and Derek, as I repeatedly asked
why a compulsory ) could not be considered a closing
On Sun, Aug 16, 2020 at 4:36 AM Benjamin Eberlei wrote:
> We have updated the RFC with all (hopefully) of the feedback from
> this discussion:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Most notable changes are:
> - A new section with several subsections on the benefits of
Hi Benjamin,
> We are looking for further feedback from the community.
Thanks, the updated RFC looks much better.
Some more feedback on why the edge cases are a concern to me,
and why the lack of an ending delimiter is similar to parsing problems already
faced.
I'd agree that restarting a
I have one major issues with the examples.
Syntax Side by Side: The properties are annotated (with attributes)
inline which is the opposited of common usage now (with annotation).
Discussion on Grouping Pro/Cons: But since this depends on the coding
style the user... No, this should be
We have updated the RFC with all (hopefully) of the feedback from this
discussion:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
Most notable changes are:
- A new section with several subsections on the benefits of a closing
delimiter / enclosing syntax.
- A section on grouping
On Mon, 10 Aug 2020, Christoph M. Becker wrote:
> On 10.08.2020 at 10:35, Derick Rethans wrote:
>
> > On Fri, 7 Aug 2020, Theodore Brown wrote:
> >
> >> - Used by other language:
> >> - This is listed as an advantage for `#[]` and `<<>>`. However, the
> >> table
> >> fails to point out
On 10.08.2020 at 10:35, Derick Rethans wrote:
> On Fri, 7 Aug 2020, Theodore Brown wrote:
>
>> - Used by other language:
>> - This is listed as an advantage for `#[]` and `<<>>`. However, the table
>> fails to point out that Hack is migrating away from `<<>>` to `@Attr`.
>
> It can only
On Fri, 7 Aug 2020, Theodore Brown wrote:
> On Fri, Aug 7, 2020 at 6:03 AM Derick Rethans wrote:
>
> > On Fri, 7 Aug 2020, Theodore Brown wrote:
> >
> > > Even if we assume the implementation is only about 30 lines, it's
> > > still extra complexity that I don't understand the benefit of. I
>
Hi everyone. I’m not a PHP internal, just a modest PHP developer. But I felt
a desire to share my observation on “@@”.
Some symbols looks very okay when doubled. For example, we use “//” for comments
and “||” for logical alternative. They are okay, because they contains only
two parallel lines.
Hello Derick & Internals,
I am a daily user of PHP and read through all the recent discussions about the
attribute syntax, and thought I could add some slightly different viewpoints
from an "end-user" who uses the current annotations a lot. This is my first time
posting, so I am hoping I am doing
>
>
> This is some new complexity, even if only a small amount right now.
> My question remains about how much more added complexity it will
> require later if we implement extensions like nested attributes.
>
What? Are you actually saying that 30 lines of code add "complexity"? I
think you
On Fri, Aug 7, 2020 at 6:03 AM Derick Rethans wrote:
> On Fri, 7 Aug 2020, Theodore Brown wrote:
>
> > Even if we assume the implementation is only about 30 lines, it's
> > still extra complexity that I don't understand the benefit of. I
> > sincerely would like to know what advantage there is
On Fri, Aug 7, 2020 at 3:32 AM Benjamin Eberlei wrote:
> On Fri, Aug 7, 2020 at 2:24 AM Theodore Brown wrote:
> > On Thu, Aug 6, 2020 at 12:30 PM Benas IML >
> > wrote:
> >
> > > Hey Theodore,
> > >
> > > On Thu, Aug 6, 2020, 8:05 PM Theodore Brown >
> > > wrote:
> > >
> > > > While none
On Fri, 7 Aug 2020 at 12:03, Derick Rethans wrote:
>
> You still haven't addressed any of the deficiencies that the other
> alternatives don't have:
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal
>
That table would be a lot more useful to steer the discussion if it was
On Fri, 7 Aug 2020, Theodore Brown wrote:
> On Thu, Aug 6, 2020 at 12:30 PM Benas IML wrote:
>
> > On Thu, Aug 6, 2020, 8:05 PM Theodore Brown wrote:
> >
> > > While none of our syntax options are perfect, I believe @@ has the
> > > best long-term tradeoffs because:
> > >
> > > - It doesn't
On Fri, Aug 7, 2020 at 2:24 AM Theodore Brown
wrote:
> On Thu, Aug 6, 2020 at 12:30 PM Benas IML
> wrote:
>
> > Hey Theodore,
> >
> > On Thu, Aug 6, 2020, 8:05 PM Theodore Brown
> wrote:
> >
> > > While none of our syntax options are perfect, I believe @@ has the
> > > best long-term tradeoffs
On Thu, Aug 6, 2020 at 12:30 PM Benas IML wrote:
> Hey Theodore,
>
> On Thu, Aug 6, 2020, 8:05 PM Theodore Brown wrote:
>
> > While none of our syntax options are perfect, I believe @@ has the
> > best long-term tradeoffs because:
> >
> > - It doesn't break useful syntax
>
> Fair enough.
>
>
Hey Theodore,
On Thu, Aug 6, 2020, 8:05 PM Theodore Brown wrote:
> On Thu, Aug 6, 2020 at 5:24 AM Benas IML
> wrote:
>
> > On Thu, 6 Aug 2020 at 11:45, Rowan Tommins
> wrote:
> >
> > > On Thu, 6 Aug 2020 at 09:12, Benas IML
> wrote:
> > >
> > > > But by sacrificing a few very old codebases
On Thu, Aug 6, 2020 at 5:24 AM Benas IML wrote:
> On Thu, 6 Aug 2020 at 11:45, Rowan Tommins wrote:
>
> > On Thu, 6 Aug 2020 at 09:12, Benas IML wrote:
> >
> > > But by sacrificing a few very old codebases (that still use `#` not `//`)
> >
> > Do you have some basis for # only being used by
> Le 6 août 2020 à 10:11, Benas IML a écrit :
>
> Ending delimiter MAY help us in the future.
>
> I really, really hate all of those arguments stating "that we should care
> only about the present, not the future" and that even though
> `#[...]`/`@[...]` might bring benefits in the future, we
A grep search was done by someone in the mailing list in the original
`<<...>>` to `@@...` RFC thread when discussing whether `#[` is going
to be a huge BC or not.
Just about all of the matches were either from old codebases or from
old PHP 3-5 Metasploit exploits, which are about 5-15 years old.
On Thu, 6 Aug 2020 at 09:12, Benas IML wrote:
>
> But by sacrificing a few very old codebases (that still use `#` not `//`)
>
Do you have some basis for # only being used by "very old" codebases? As
far as I'm aware, it's not deprecated, and while the PEAR style guide
listed it as
On Thu, Aug 6, 2020 at 9:18 AM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:
> Le Thu, 6 Aug 2020 07:48:05 +0100 (BST),
> Derick Rethans a écrit :
> > From the RFC:
> > - No ending delimiter
>
> As said before, it does have an ending delimiter when they are arguments
> since
> there
On Thu, 6 Aug 2020 at 07:40, Derick Rethans wrote:
> On Wed, 5 Aug 2020, Rowan Tommins wrote:
> > The confusing thing about this argument is that as soon as they have
> > arguments, attributes will have an ending delimiter _whatever_ syntax
> > we choose, because nobody has ever proposed
On Thu, Aug 6, 2020, 10:18 AM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:
> Le Thu, 6 Aug 2020 07:48:05 +0100 (BST),
> Derick Rethans a écrit :
> > From the RFC:
> > - No ending delimiter
>
> As said before, it does have an ending delimiter when they are arguments
> since
> there
On Thu, 6 Aug 2020 at 08:18, Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:
> As said before, it does have an ending delimiter when they are arguments
> since
> there is the parenthesis around them. When there are no arguments I don’t
> see
> the benefit of an ending delimiter, it’s
Le Thu, 6 Aug 2020 07:48:05 +0100 (BST),
Derick Rethans a écrit :
> From the RFC:
> - No ending delimiter
As said before, it does have an ending delimiter when they are arguments since
there is the parenthesis around them. When there are no arguments I don’t see
the benefit of an ending
On Wed, 5 Aug 2020, Rowan Tommins wrote:
> On 05/08/2020 18:10, David Rodrigues wrote:
>
> > With error supression remotion (9.0?) it could be used for other new
> > features easily.
>
>
> Just to re-iterate something that I'm pretty sure has been said
> before: the chance of removing the
On Tue, 4 Aug 2020, Theodore Brown wrote:
>
> #[Attr1, Attr2] # 15 chars
>
> @@Attr1 @@Attr2 # 15 chars
>
> # 4 lines, 53 chars not counting whitespace
> @[
> AttrWithParam("foobar"),
> SomeOtherAttr("fizzbuzz"),
> ]
>
> # 2 lines, 52 chars
>
On Wed, 5 Aug 2020, Rowan Tommins wrote:
> On Wed, 5 Aug 2020 at 13:20, Benjamin Eberlei wrote:
>
> > It looks nice for a simple attribute like @@Jit, or for a one
> > without arguments like the used @@Deprecated, but as soon as there
> > are more than one, and they each get arguments,
On 05/08/2020 18:10, David Rodrigues wrote:
With error supression remotion (9.0?) it could be used
for other new features easily.
Just to re-iterate something that I'm pretty sure has been said before:
the chance of removing the error suppression operator in PHP 9.0 is
approximately zero,
A new suggestion: @attr(...). It could be used on future for other syntaxes
and should be supersedes the error supression. So will be a BC exclusively
for @attr() error supression for attr() function. But it is few verbose and
easy to understand. With error supression remotion (9.0?) it could be
On Wed, Aug 5, 2020 at 7:20 AM Benjamin Eberlei wrote:
> On Tue, Aug 4, 2020 at 6:37 PM Theodore Brown wrote:
> > On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans wrote:
> >
> > > Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> > > Syntax Change RFC to reflect that process:
On Wed, 5 Aug 2020 at 13:20, Benjamin Eberlei wrote:
>
> It looks nice for a simple attribute like @@Jit, or for a one without
> arguments like the used @@Deprecated, but as soon as there are more than
> one, and they each get arguments, enclosing them has its own benefits over
> them just
On Tue, 4 Aug 2020, Pedro Magalhães wrote:
> I'd like to reinforce the idea that this RFC (as all RFCs) needs a
> Yes/No primary vote which should attain a 2/3 majority to pass.
I'll make that clear in the RFC, that was obviously my intention.
cheers,
Derick
--
PHP 7.4 Release Manager
Host
On Tue, 4 Aug 2020, Levi Morrison wrote:
> > I agree with Theodore's points, including that this is metadata on a
> > declaration, not a declaration itself.
>
> Is this technically true? I haven't peeked at the grammar. I suspect
> it is a declaration and not an optional piece of data on a
>
On Tue, Aug 4, 2020 at 6:37 PM Theodore Brown
wrote:
> On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans wrote:
>
> > Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> > Syntax Change RFC to reflect that process:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
Hi Theodore,
> I meant to say "statement", e.g.
> I suspect it is a statement and not an optional piece of data on a
> statement, like say `public`.
I assume this would boil down to a disagreement on what we mean by statement,
and could be clarified by using whatever that definition was instead
On Tue, Aug 4, 2020 at 8:59 PM Levi Morrison
wrote:
>
> > I agree with Theodore's points, including that this is metadata on a
> > declaration, not a declaration itself.
>
> Is this technically true? I haven't peeked at the grammar. I suspect
> it is a declaration and not an optional piece of
> I agree with Theodore's points, including that this is metadata on a
> declaration, not a declaration itself.
Is this technically true? I haven't peeked at the grammar. I suspect
it is a declaration and not an optional piece of data on a
declaration, like say `public`.
--
PHP Internals - PHP
Hi Derick,
> Hi Derick,
>
> I don't agree with the main argument put forward in this RFC:
>
> > The main concern is that @@ has no ending symbol and it's
> > inconsistent with the language that it would be the only
> > declaration or statement in the whole language that has no ending
> >
Hi Derick,
> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> Syntax Change RFC to reflect that process:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Patches and comments welcome.
1. I feel like "Changes the lexing of **remaining** tokens" should also
Hi all,
> On Aug 4, 2020, at 17:07, Pedro Magalhães wrote:
>
> I'd like to reinforce the idea that this RFC (as all RFCs) needs a Yes/No
> primary vote which should attain a 2/3 majority to pass. As it was the case
> with https://wiki.php.net/rfc/shorter_attribute_syntax, it had a primary
>
Hi Derick,
I'd like to reinforce the idea that this RFC (as all RFCs) needs a Yes/No
primary vote which should attain a 2/3 majority to pass. As it was the case
with https://wiki.php.net/rfc/shorter_attribute_syntax, it had a primary
vote asking "Are you okay with re-voting on the attribute
On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans wrote:
> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> Syntax Change RFC to reflect that process:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Patches and comments welcome.
Hi Derick,
I don't agree with
On Tue, 4 Aug 2020, Sara Golemon wrote:
> On Tue, Aug 4, 2020 at 9:03 AM Benjamin Eberlei wrote:
>
> > It provides a small BC break where code written as @[$foo, $bar] =
> > baz(); or $foo = @["bar" => $baz]; will not compile on PHP 8
> > anymore, but that can be easily fixed by writing it
On 04/08/2020 16:19, Sebastian Bergmann wrote:
Am 04.08.2020 um 15:45 schrieb Derick Rethans:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
This is probably a wiki/markup issue: the RFC shows "«Attr»" instead
of "<>" for the original syntax.
Given that every single thread about
On Tue, Aug 4, 2020 at 9:03 AM Benjamin Eberlei wrote:
> It provides a small BC break where code written as @[$foo, $bar] = baz();
> or $foo = @["bar" => $baz]; will not compile on PHP 8 anymore, but that can
> be easily
> fixed by writing it with a space between @ and [.
>
> If those are the
On Tue, Aug 4, 2020 at 4:19 PM David Rodrigues
wrote:
> Suggestions:
>
> $(Attribute()) (available)
> $[Attribute()] (available)
> <> 2)>> (like strings escapes)
>
I had someone else suggest $[] to me today as well, funny coincidence :-)
Can you take the "@@ to @[] pull" request as a starting
On Tue, Aug 4, 2020 at 4:19 PM David Rodrigues
wrote:
> Suggestions:
>
> $(Attribute()) (available)
> $[Attribute()] (available)
> <> 2)>> (like strings escapes)
>
The syntax for the first two seems oddly pleasing when used within PHP.
Suggestions:
$(Attribute()) (available)
$[Attribute()] (available)
<> 2)>> (like strings escapes)
About $() syntax:
- Number of required characters: (2+1)
- Has end delimiter: yes
- Allow grouping: yes
- Forward compatibility in PHP 7: yes
- Breaks BC of valid PHP 7 codes: no
Am 04.08.2020 um 15:45 schrieb Derick Rethans:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
This is probably a wiki/markup issue: the RFC shows "«Attr»" instead of
"<>" for the original syntax.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi,
Am 04.08.20 um 15:45 schrieb Derick Rethans:
> Patches and comments welcome.
if the syntax will be changed to having a closing delimiter, I would
really like to have symmetrical delimiters, like @{ }@ or something like
that. ] as a closing delimiter just seems to collide with the array
On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote:
> Hi,
>
> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> Syntax Change RFC to reflect that process:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Patches and comments welcome.
>
> FWIW, this has an
A little nitpick but I don't think that `@@` really signals familiarity
with docblocks.
Nevertheless, I really like `@[...]`. I think it combines best of the both
worlds (little-to-no BC breaks, ending delimiter, etc.) and also looks
aesthetically pleasing.
Best regards,
Benas
On Tue, Aug 4,
Hi,
Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
Syntax Change RFC to reflect that process:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
Patches and comments welcome.
FWIW, this has an excemption from the RM Sara as per [2]:
> * Shorter Attribute Syntax
On Wed, June 10, 2020 at 3:11 AM Michał Brzuchalski
wrote:
> I just noticed a power of Rusts outer attributes which this syntax
> count follow in a future. Following outer attributes in Rust's we
> could introduce in a future syntax like
>
>
Hi Sebastian,
On Wed, June 10, 2020 at 12:37 AM Sebastian Bergmann wrote:
> Am 09.06.2020 um 17:57 schrieb Theodore Brown:
> > That's an interesting argument. After thinking about it more, though,
> > I'm not sure I understand what the benefit would be. The docblock
> > annotation needed for
wt., 9 cze 2020 o 13:56 Benjamin Eberlei napisał(a):
> On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown
> wrote:
>
> > Hi internals,
> >
> > I discussed the syntax for attributes further with Benjamin, Martin,
> > and several other internals developers off-list, and with their
> > feedback
On Tue, Jun 9, 2020 at 6:57 PM Theodore Brown
wrote:
> Hi Benjamin,
>
> On Tue, June 9, 2020 at 6:55 AM Benjamin Eberlei wrote:
>
> > Larry's suggestion about `#[Attr]` makes an important argument about
> > allowing to declare attributes in code in PHP 7 in a forward compatible
> > way that has
Am 09.06.2020 um 17:57 schrieb Theodore Brown:
That's an interesting argument. After thinking about it more, though,
I'm not sure I understand what the benefit would be. The docblock
annotation needed for PHP 7 is *already* forward compatible with PHP 8.
So wouldn't this just be duplicating the
Hi Benjamin,
On Tue, June 9, 2020 at 6:55 AM Benjamin Eberlei wrote:
> Larry's suggestion about `#[Attr]` makes an important argument about
> allowing to declare attributes in code in PHP 7 in a forward compatible
> way that has not been brought up before.
>
> ```php
> /** @ORM\Entity */
>
Am 09.06.2020 um 13:55 schrieb Benjamin Eberlei:
Larry's suggestion about #[Attr] makes an important argument about allowing
to declare attributes in code in PHP 7 in a forward compatible way that has
not been brought up before.
/** @ORM\Entity */
#[ORM\Entity]
class User {}
This code would
On Tue, Jun 9, 2020 at 2:07 PM Lynn wrote:
>
>
> On Tue, Jun 9, 2020 at 1:55 PM Benjamin Eberlei
> wrote:
>
>> Larry's suggestion about #[Attr] makes an important argument about
>> allowing
>> to declare attributes in code in PHP 7 in a forward compatible way that
>> has
>> not been brought up
+1
On Tue, Jun 9, 2020, 2:56 PM Benjamin Eberlei wrote:
> On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown
> wrote:
>
> > Hi internals,
> >
> > I discussed the syntax for attributes further with Benjamin, Martin,
> > and several other internals developers off-list, and with their
> > feedback
On Tue, Jun 9, 2020 at 1:55 PM Benjamin Eberlei wrote:
> Larry's suggestion about #[Attr] makes an important argument about allowing
> to declare attributes in code in PHP 7 in a forward compatible way that has
> not been brought up before.
>
> /** @ORM\Entity */
> #[ORM\Entity]
> class User {}
On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown
wrote:
> Hi internals,
>
> I discussed the syntax for attributes further with Benjamin, Martin,
> and several other internals developers off-list, and with their
> feedback completed an RFC proposing to use the shorter `@@` syntax
> instead of `<<>>`
On Mon, June 8, 2020 at 1:08 PM Markus Fischer wrote:
> I noticed that my `@` character did bleed/meld almost with the first
> character of the attribute name...wide characters like the `M` almost
> touch the `@`.
Hi Markus,
The first question that comes to my mind is, wouldn't this also be
Hi Markus,
On 08/06/2020 19:08, Markus Fischer wrote:
Since we humans read source more often then we write, I can only
suggest to everyone to conduct their own "visual" testing first and
not just judge on technical merits => I think it makes sense to
consider both here, since we're already
On Mon, June 8, 2020 at 10:01 AM Larry Garfield wrote:
> FWIW, I find both alternatives ugly to my eye. So, there's that.
>
> Given that `@` is off the table for obvious reasons, my preference
> would frankly be for Rust's `#[]`, which has the nice side effect
> of being a normal comment in
1 - 100 of 124 matches
Mail list logo
