Le Tue, 28 Jul 2020 17:57:34 +,
Theodore Brown a écrit :
> Rust chose to use #[] even though it wasn't used by any other language.
> Does that make it a bad fit for Rust? No. But just because Rust uses
> a syntax also doesn't mean it's a good fit for PHP.
For those which like me do not know
On Sun, Aug 2, 2020 at 4:40 PM Dan Ackroyd wrote:
> Theodore Brown wrote:
> >
> > The Shorter Attribute Syntax RFC explicitly mentioned that the @@
> > syntax would supersede the grouped attributes proposal: [1]
>
> From the RFC:
> >
> > # Unaffected Functionality
> > ...it will supersede the
On Sun, Aug 2, 2020 at 10:11 AM Derick Rethans wrote:
> On Thu, 30 Jul 2020, Benjamin Eberlei wrote:
>
> > I think it has become clear that we need to revisit this syntax question
> > again, including the elephpant in the room of delaying this feature to
> 8.1.
> >
> > The reason is not only
Theodore Brown wrote:
>
> The Shorter Attribute Syntax RFC explicitly mentioned that the @@
> syntax would supersede the grouped attributes proposal: [1]
>From the RFC:
>
> # Unaffected Functionality
> ...it will supersede the syntax for grouped attributes.
I missed that change at least in part
On Sun, Aug 2, 2020 at 10:06 AM Derick Rethans wrote:
> On Wed, 29 Jul 2020, Benjamin Eberlei wrote:
>
> > Personally I favor #[] myself, but there has been a vote with a
> > substantial participation choosing @@. Overturning this democratic
> > outcome should require **significant** technical
On Thu, 30 Jul 2020, Benjamin Eberlei wrote:
> I think it has become clear that we need to revisit this syntax question
> again, including the elephpant in the room of delaying this feature to 8.1.
>
> The reason is not only Joe's desire to revote on #[], but also that there
> are now more
On Wed, 29 Jul 2020, Benjamin Eberlei wrote:
> Personally I favor #[] myself, but there has been a vote with a
> substantial participation choosing @@. Overturning this democratic
> outcome should require **significant** technical arguments, otherwise
> this RFC would provide problematic
HI,
[disclosure: I'm not php internals/interpreter developer; have ~10 years of
using php language]
I've searched but couldn't find in this discussion:
Can we keep the 'current' [doctrine/annotations or similar libraries]
annotation syntax and implement parsing of metadata in PHPinterpreter?
Hi Joe Ferguson,
> Now that it seems the technical concerns around @@ have been resolved by
> another pending, passing, RFC, I'm still here wanting us to talk about the
> impact of @@ on static analysis tools. Apparently, internals doesn't care
> about these projects. I care and I'm trying to
On Thu, Jul 30, 2020 at 12:30 PM Rowan Tommins wrote:
>
> On Thu, 30 Jul 2020 at 17:18, guilhermebla...@gmail.com <
> guilhermebla...@gmail.com> wrote:
>
> >
> > I bet a search/replace wouldn't be that hard to be achieved
> >
>
>
> Find-and-replace always sounds like a good idea, until you
On Thu, 30 Jul 2020 at 17:18, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
>
> I bet a search/replace wouldn't be that hard to be achieved
>
Find-and-replace always sounds like a good idea, until you realise that
people run *a lot* of third-party code. I would not enjoy going
On Thu, Jul 30, 2020 at 6:19 PM guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> Question: The key factor of not using @ is due to conflict of
> suppression symbol.
> While we are in a major (where BC breaks are not encourage, but
> tolerable), have we considered the possibility of
Question: The key factor of not using @ is due to conflict of
suppression symbol.
While we are in a major (where BC breaks are not encourage, but
tolerable), have we considered the possibility of BC breaking
suppression symbol (@ would become @@) and using @ for Attributes?
I bet a search/replace
On Thu, 30 Jul 2020 at 14:28, Joe Ferguson wrote:
> ... I'm still here wanting us to talk about the
> impact of @@ on static analysis tools. Apparently, internals doesn't care
> about these projects.
>
I don't think that's a reasonable summary of this thread at all. I've seen
three main types
I think that verbosity is not a problem if compared to "strange mixed
symbols", mainly to new users. Google it is a bit hard "what means double
at". And "using attribute" is very clear.
Anyway, I think that is valid we use it for now until we have a good symbol
arrangement, and on future we could
Hi David,
> I would like to suggests the syntax "using attribute(Attribute, ...)". It
> is more clear and should not create BC.
I'd agree that it's implementable and works with the tokenizer.
My main objection is the verbosity, which is the reason I assume many other
languages have fairly
Hi Benjamin,
> The reason is not only Joe's desire to revote on #[], but also that there
> are now more syntax proposals such as @[] by Derick or @@ in comments by
> Tyson (though no patch exists for it yet). At this point a lot of syntaxes
> are potentially viable (except single @, please don't
I would like to suggests the syntax "using attribute(Attribute, ...)". It
is more clear and should not create BC.
Em qui, 30 de jul de 2020 10:28, Joe Ferguson escreveu:
> On Thu, Jul 30, 2020 at 7:50 AM Benjamin Eberlei
> wrote:
>
> > I think it has become clear that we need to revisit this
On Thu, Jul 30, 2020 at 7:50 AM Benjamin Eberlei
wrote:
> I think it has become clear that we need to revisit this syntax question
> again, including the elephpant in the room of delaying this feature to 8.1.
>
> The reason is not only Joe's desire to revote on #[],
>
>
No, I *do not* want to
I think it has become clear that we need to revisit this syntax question
again, including the elephpant in the room of delaying this feature to 8.1.
The reason is not only Joe's desire to revote on #[], but also that there
are now more syntax proposals such as @[] by Derick or @@ in comments by
Hi Theodore,
śr., 29 lip 2020 o 21:08 Theodore Brown napisał(a):
> ...
> Anyway, apart from the fact that feature freeze is less than a week
> away, it seems like voting again to use #[] instead of @@ would
> violate the voting rules. [1] It hasn't been six months since the
> last vote, and
On Tue, July 28, 2020 at 6:09 PM Mark Randall wrote:
> On 28/07/2020 22:55, Theodore Brown wrote:
> > I appreciate the examples. I think there are good reasons not to
> > implement these kind of extensions, at least in this form. I'll reply
> > to each example below.
>
>
> The problem is your
Hi Joe,
wt., 28 lip 2020 o 16:47 Joe Ferguson napisał(a):
> Hello Internals,
>
> I've been working with Derick Rethans and others (thanks all!) on a Shorter
> Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax
> would be preferred over the currently agreed upon "@@" syntax
Hi internals,
I had thought of another alternative syntax - `/** @@MyAttribute */`, which
would solve some of the problems I mentioned about `#[`.
```
namespace My\NS;
use Other\MyAttribute;
/**
* Use @@ or << at the start of a line. (To be determined)
* Resolve the names in the comment
Hi Michal,
> On Jul 29, 2020, at 01:13, Michał Marcin Brzuchalski
> wrote:
>
> Hi Paul,
>
> wt., 28 lip 2020 o 20:56 Paul M. Jones napisał(a):
>
>> ...
>> Let's count. + is "change away from @@ to anything else", - is "stay with
>> @@", ? is hard-to-tell/weak/uncertain/they-all-suck.
>> ...
Hello Internals,
Here is a small comparison table based on current feedback, maybe it
will bring some objective clarity to the discussion:
(markdown below)
Impact|`@@`|`#[]`
---|---|---
BC break|virtualy nonexistent|slightly broader: `##[` comments are now broken.
Parser|no technical problems by
On Wed, Jul 29, 2020 at 2:21 AM tyson andre
wrote:
> Hi internals,
>
> For #[, my main objection is the various ways this can change the lexing
> in a way that is impractical to (efficiently) backfill,
> and that the proposed patch doesn't address the fact that the syntax may
> change the syntax
Hi Paul,
wt., 28 lip 2020 o 20:56 Paul M. Jones napisał(a):
> ...
> Let's count. + is "change away from @@ to anything else", - is "stay with
> @@", ? is hard-to-tell/weak/uncertain/they-all-suck.
> ...
> Michal Brzuchalski: -?
>
Wow. Hold on your horses. I was never in favour for @@ but
Hi Joe,
Personally I favor #[] myself, but there has been a vote with a substantial
participation choosing @@. Overturning this democratic outcome should
require **significant** technical arguments, otherwise this RFC would
provide problematic precedent for any RFC to be overturned by arbitrary
Hi internals,
For #[, my main objection is the various ways this can change the lexing in a
way that is impractical to (efficiently) backfill,
and that the proposed patch doesn't address the fact that the syntax may change
the syntax of php 7 code in unexpected ways.
This syntax would help
On 28/07/2020 22:55, Theodore Brown wrote:
I appreciate the examples. I think there are good reasons not to
implement these kind of extensions, at least in this form. I'll reply
to each example below.
The problem is your argument comes from a position of... because you
don't like those
On Tue, July 28, 2020 at 2:38 PM Mark Randall wrote:
> On 28/07/2020 18:57, Theodore Brown wrote:
> >> Having a closing ] makes it easier to extend Attributes with more syntax
> >
> > This might be a good argument if there were actually a need to extend
> > attributes with more syntax. What
(Top posting because... sue me.)
I hereby propose to use @[] syntax for attributes.
No need to vote; it's clearly the best, nay only, real option.
Make it so.
P.S. Sorry for suggesting @@ earlier, I've no idea what I was thinking.
Creating new syntax is HARD!
P.P.S. <3
On Tue, 28 Jul 2020 at
Hi,
>
> On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown
> wrote:
>
> >
> > Hi Joe,
> >
> > From the perspective of looks alone I don't care much one way or the
> > other between @@ and #[]. However, I don't find the arguments for #[]
> > in this RFC very compelling, and it ignores some of the
On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown
wrote:
>
> Hi Joe,
>
> From the perspective of looks alone I don't care much one way or the
> other between @@ and #[]. However, I don't find the arguments for #[]
> in this RFC very compelling, and it ignores some of the other downsides
> of #[]
> On Jul 28, 2020, at 14:15, Ben Ramsey wrote:
>
>> On Jul 28, 2020, at 14:10, Paul M. Jones wrote:
>>
>>> On Jul 28, 2020, at 14:07, Ben Ramsey wrote:
>>>
On Jul 28, 2020, at 13:55, Paul M. Jones wrote:
Now, it may be that #[] or <<>> or something else actually is
On 28/07/2020 18:57, Theodore Brown wrote:
Having a closing ] makes it easier to extend Attributes with more syntax
This might be a good argument if there were actually a need to extend
attributes with more syntax. What other languages have found a need for
this? Even Rust doesn't allow
> On Jul 28, 2020, at 14:10, Paul M. Jones wrote:
>
>> On Jul 28, 2020, at 14:07, Ben Ramsey wrote:
>>
>>> On Jul 28, 2020, at 13:55, Paul M. Jones wrote:
>>>
>>> Now, it may be that #[] or <<>> or something else actually is "better" in
>>> some sense that cannot be articulated. But if
> On Jul 28, 2020, at 14:07, Ben Ramsey wrote:
>
>> On Jul 28, 2020, at 13:55, Paul M. Jones wrote:
>>
>> Now, it may be that #[] or <<>> or something else actually is "better" in
>> some sense that cannot be articulated. But if there are no existing
>> technical hurdles to be overcome
> On Jul 28, 2020, at 13:55, Paul M. Jones wrote:
>
> Now, it may be that #[] or <<>> or something else actually is "better" in
> some sense that cannot be articulated. But if there are no existing technical
> hurdles to be overcome with the already-voted-on-and-accepted solution of @@,
>
Hi all,
> On Jul 28, 2020, at 12:57, Theodore Brown wrote:
>
>> On Tue, July 28, 2020 at 9:46 AM Joe Ferguson wrote:
>>
>> ...
>>
>> Feedback to Derick's tweet
>> (https://twitter.com/derickr/status/1285912223639130114)
>> were [sic] overwhelmingly positive
>
> Are you sure? I took a look
On Tue, July 28, 2020 at 9:46 AM Joe Ferguson wrote:
> Hello Internals,
>
> I've been working with Derick Rethans and others (thanks all!) on a Shorter
> Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax
> would be preferred over the currently agreed upon "@@" syntax for
Am 28.07.2020 um 17:50 schrieb Derick Rethans:
This is an excellent RFC highlighting the important deficiencies of the
@@ syntax.
I hope you will all read this and also conclude that we can still pick
this better syntax.
Remember that it is not only about how it looks. It is much more
On Tue, 28 Jul 2020, Joe Ferguson wrote:
> I've been working with Derick Rethans and others (thanks all!) on a
> Shorter Attribute Syntax Change RFC which outlines reasons why the
> "#[]" syntax would be preferred over the currently agreed upon "@@"
> syntax for Shorter Attribute Syntax.
This
> On Jul 28, 2020, at 10:13, Côme Chilliet
> wrote:
>
> Le Tue, 28 Jul 2020 09:46:38 -0500,
> Joe Ferguson a écrit :
>
>> Hello Internals,
>>
>> I've been working with Derick Rethans and others (thanks all!) on a Shorter
>> Attribute Syntax Change RFC which outlines reasons why the "#[]"
Le Tue, 28 Jul 2020 09:46:38 -0500,
Joe Ferguson a écrit :
> Hello Internals,
>
> I've been working with Derick Rethans and others (thanks all!) on a Shorter
> Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax
> would be preferred over the currently agreed upon "@@" syntax
46 matches
Mail list logo
