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
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 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 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
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
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
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
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
> 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
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
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, 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
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
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
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
> 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
> 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 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 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: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 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
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
(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
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
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 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
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
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
https://phil.tech/2013/wtf-is-t-paamayim-nekudotayim/
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
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
31 matches
Mail list logo
