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 always
We read phil's post years ago (it is from 2013).
Do you have anything new to contribute to the discourse other than
posting a link to a post from 7 years ago?
If so, you should present that and not old web pages .
Walter
On Tue, Jul 28, 2020 at 7:31 PM Ryan Jentzsch wrote:
>
> https://phil.tec
https://phil.tech/2013/wtf-is-t-paamayim-nekudotayim/
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
re
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 php
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 exampl
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 other
On 28/07/2020 19:22, Niklas Keller wrote:
Do we handle 1XX responses, yet?
https://tools.ietf.org/html/rfc7231#section-6.2
Yes, as of this patch a few years back:
https://github.com/php/php-src/pull/2175/files
This is what implementations should do, see
https://tools.ietf.org/html/rfc72
(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 2
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 oth
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 #[] co
> 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 "better"
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 additio
> 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 there
> 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 with
> 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 @@,
> what
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 a
Hey all,
>
> > Given that it's a very small change, the RFC is probably not necessary,
> in
> > which case it's not too late, however I'd like some clarification about
> > what this actually offers over defaulting to 1.0.
>
One thing it offers is detecting truncated responses. Servers will often
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 Sh
On Tue, Jul 28, 2020 at 3:52 AM Rowan Tommins
wrote:
> The risk of advertising 1.0 by default is that some software will have been
> programmed to outright refuse that protocol version. I don't know of any
> recent examples, but this bug report from 2007 was for a SOAP endpoint that
> returned 50
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
important
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 "#[]" synt
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
Also be sure to add the mailing list address as the final email - the one you
want to send emails to.
This is the part I missed and received the same error.
I don’t know if this counts as the captcha but the label is somewhat confusing,
which is perfect if it’s meant to be the captcha Kalle men
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 Shorter
Attribute Syntax.
An important part of the research that w
On 7/28/2020 08:31, Nikita Popov wrote:
However, with my RM hat on, I need to feel like we're as sure as we can be
about this syntax before it's public.
I'm willing to extend an additional period (up to the tagging of beta3, in
just under six weeks) for a re-vote on the syntax as changing that
On Thu, Jul 23, 2020 at 6:46 PM Sara Golemon wrote:
> On Thu, Jul 23, 2020 at 10:19 AM Sara Golemon wrote:
>
> > If that's the case, then the solution still seems obvious: Defer
> > attributes to 8.1.
> >
> > After some discussion off list, including Nikita (who is probably closer
> to this "pro
Hi Rowan,
Den 2020-07-28 kl. 10:52, skrev Rowan Tommins:
Hi Sara,
On Tue, 28 Jul 2020 at 00:24, Sara Golemon wrote:
Given that it's a very small change, the RFC is probably not necessary, in
which case it's not too late, however I'd like some clarification about
what this actually offers ov
On Tue, 28 Jul 2020 at 10:13, Eliot Lear wrote:
> I think this is ok for a client. I'd feel differently about servers.
> There may be other subtle changes between 1.0 and 1.1. Have you
> reviewed those?
>
I did my best; see previous mails in this thread for my analysis. It's
surprisingly hard
Hi Sara,
On Tue, 28 Jul 2020 at 00:24, Sara Golemon wrote:
>
> Given that it's a very small change, the RFC is probably not necessary, in
> which case it's not too late, however I'd like some clarification about
> what this actually offers over defaulting to 1.0.
>
That's a very reasonable que
31 matches
Mail list logo
