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 o
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 attrib
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 b
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 snowflake
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 per
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 mentio
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:
>>
>> https://wiki.php.net/rfc/shorter_attribute_syn
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 to
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 c
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 re
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 namespa
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 en
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 exce
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 u
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 cha
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 of
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 gr
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 Delim
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 "si
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 rath
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, stand
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,
M
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 pa
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 n
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 cha
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 expre
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 of
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 de
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 two-w
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 consul
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 pro/con
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 t
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 do
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. Th
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 should
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 o
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 of
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
acco
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 br
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 (t
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 "v
> 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 "discouraged"
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 removing
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 i
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 e
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 delimit
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 erro
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
> @@AttrW
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, enclosi
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, an
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 us
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 standi
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 of
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
> dec
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 dat
> 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
> > terminati
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 b
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
> vote
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 syntax
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 wit
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 a
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 pot
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 p
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: https:/
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
syntax
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 exce
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, 202
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
>
> #![StrictTypes,Module("my_module"),Opcache(s
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 PHP
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 complete
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 n
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 a
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 */
> #[ORM\
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 wor
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 b
+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 comp
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 an
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 di
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 ear
Hi Theodore,
On 08.06.20 06:36, Theodore Brown wrote:
```php
// 170 characters for attributes (162 not counting leading whitespace)
<<
ManyToMany(Phonenumber::class),
JoinTable("users_phonenumbers"),
JoinColumn("user_id", "id"),
InverseJoinColumn("phonenumber_id", "id", JoinColumn::U
1 - 100 of 122 matches
Mail list logo
