Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

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 comparing to complexity of type definitions
> > - removal of the machine reading section as too narrow and
> >   ultimately not that important as downstream libraries just have to
> >   deal with any of it
> > - some more nuances in forward compatibility pro/cons section of #[]
> > - smaller corrections and improvements.
> >
> > I don't think something major is missing now.
>
> Hi Benjamin,
>
> Thanks for the updates. I just have a few more thoughts on aspects
> that haven't been mentioned before:
>
> 1. The **Attributes are not like Modifiers** section makes an
>argument that having an end delimiter "groups docblock comment and
>attributes into two similarly shaped syntax blocks that prefix the
>declaration increasing familiarity."
>
> In my own (admittedly subjective) opinion, an end delimiter on
> attributes actually increases confusion when there is also a
> docblock. To reuse the example from the RFC:
>
> /**
>  * A comment describing things.
>  *
>  * @psalm-suppress SomeRule
>  */
> #[
> ORM\Entity(),
> ORM\Table("baz")
> ]
> final class Something {
> }
>
> Because the attribute group has its own start and end delimiters, it
> almost looks like the doc comment applies to the attribute block
> rather than the class.
>
> With the `@@` or `@:` syntax, it seems clearer that attributes are
> part of the class/function/property declaration, rather than their
> own standalone construct which docblocks can be applied to:
>
> /**
>  * A comment describing things.
>  *
>  * @psalm-suppress SomeRule
>  */
> @@ORM\Entity
> @@ORM\Table("baz")
> final class Something {
> }
>
>
> Given that the only complex part of an attribute is the optional
> argument list, which already has its own start/end delimiters, I
> ultimately don't find the "complexity" argument very compelling for
> needing an additional attribute end delimiter besides.
>

>
> 2. In the **Discussion on grep'ability** section, the RFC says
>"Enforcement of same line is also not the case for other
>declarations that benefit from grep'ability such as classes,
>functions, constants and so on in PHP already, so this is not
>consistent within the language."
>
> This seems to be outdated information, based on Martin's original
> patch before the "Treat namespaced names as single token" RFC was
> accepted. In the current `@@` implementation, there is no single-line
> enforcement, consistent with other parts of the language.
>

Right, i didn't realize this restriction was lifted and updated this
section.

This doesn't change the argument though that when you need coding styles to
enforce a particular style that grepability works, then you can find a
coding standard with all syntaxes that has good grepability, i.e. by not
using grouping.

>
> Not having whitespace between the attribute token and name would be
> enforced by coding style conventions, just as is the case with
> function/class/constant definitions.
>
> Note that there is some precedent in PHP for choosing syntax that
> ensures easier searching (for example, the decision to place return
> type declarations after the parameter list rather than before the
> function name).
>
> Grep'ability isn't a big deal when finding usages in an IDE, but
> sometimes there is a need to search code on a server or other source
> without an IDE, in which case easy grep'ability can be very helpful.
>
> Sincerely,
> Theodore

Re: [PHP-DEV] HTTP/1.1 by default in PHP 8.0

[Matteo Beccati]

Hi Rowan,

On 17/08/2020 18:36, Rowan Tommins wrote:
> On Mon, 17 Aug 2020 at 16:21, Matteo Beccati  wrote:
>>
>> FWIW, I've just been hit by https://bugs.php.net/bug.php?id=47021 in a
>> SOAP response from a server using "Transfer-Encoding:> spaces>chunked". I see the bug is still open, although the comments to
>> the PR hint to the fact that it should have been fixed.
> 
> Thanks for the heads up; if you can manage to get a test case, I'll have
> another look over it as soon as I have time.

I've just pushed what I think is the fix to the last remaining instance
of whitespace issues with HTTP headers, this time when parsing the SOAP
response. The fix is fairly similar to the one you made in the http
fopen wrapper. SOAP tests are passing and valgrind doesn't complain, but
an extra set of eyes on my commit would be appreciated.

The commit also close the bug report, which I think is good anyway.


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Theodore Brown]

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 reading section as too narrow and 
>   ultimately not that important as downstream libraries just have to
>   deal with any of it
> - some more nuances in forward compatibility pro/cons section of #[]
> - smaller corrections and improvements.
> 
> I don't think something major is missing now.

Hi Benjamin,

Thanks for the updates. I just have a few more thoughts on aspects
that haven't been mentioned before:

1. The **Attributes are not like Modifiers** section makes an
   argument that having an end delimiter "groups docblock comment and
   attributes into two similarly shaped syntax blocks that prefix the
   declaration increasing familiarity."

In my own (admittedly subjective) opinion, an end delimiter on
attributes actually increases confusion when there is also a
docblock. To reuse the example from the RFC:

/**
 * A comment describing things.
 *
 * @psalm-suppress SomeRule
 */
#[
ORM\Entity(),
ORM\Table("baz")
]
final class Something {
}

Because the attribute group has its own start and end delimiters, it
almost looks like the doc comment applies to the attribute block
rather than the class.

With the `@@` or `@:` syntax, it seems clearer that attributes are
part of the class/function/property declaration, rather than their
own standalone construct which docblocks can be applied to:

/**
 * A comment describing things.
 *
 * @psalm-suppress SomeRule
 */
@@ORM\Entity
@@ORM\Table("baz")
final class Something {
}


Given that the only complex part of an attribute is the optional
argument list, which already has its own start/end delimiters, I
ultimately don't find the "complexity" argument very compelling for
needing an additional attribute end delimiter besides.


2. In the **Discussion on grep'ability** section, the RFC says
   "Enforcement of same line is also not the case for other
   declarations that benefit from grep'ability such as classes,
   functions, constants and so on in PHP already, so this is not
   consistent within the language."

This seems to be outdated information, based on Martin's original
patch before the "Treat namespaced names as single token" RFC was
accepted. In the current `@@` implementation, there is no single-line
enforcement, consistent with other parts of the language.

Not having whitespace between the attribute token and name would be
enforced by coding style conventions, just as is the case with
function/class/constant definitions.

Note that there is some precedent in PHP for choosing syntax that
ensures easier searching (for example, the decision to place return
type declarations after the parameter list rather than before the
function name).

Grep'ability isn't a big deal when finding usages in an IDE, but
sometimes there is a need to search code on a server or other source
without an IDE, in which case easy grep'ability can be very helpful.

Sincerely,  
Theodore
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Jakob Givoni]

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 namespace token RFC to be viable.
>> > While this is not a problem anymore, the @@ syntax might not have come out 
>> > on top if this information was known beforehand.
>>
>> If anything, this is an argument AGAINST this RFC. A "bad" decision
>> was taken. The problem with it was fixed. No need to change anything.
>> The argument comes across as disingenuous, I'm afraid.
>
> 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.
>

Don't really understand how that is a response to my argument.
However, I understand your opinion, I just find it hard to find
convincing evidence in support of it in this RFC.

>>
>> Moving on...
>>
>> > The #[] syntax provides the benefit of forward compatibility, but this 
>> > also introduces some potential problems for PHP 7 code.
>> > An alternative syntax @[] was suggested to eleviate these problems which 
>> > was not previously voted on.
>>
>> Ok, let's analyze the logic here as well: #[] lost the vote. #[] would
>> have had some problems. Are there any
>
>
> What problems? Besides the BC breaks that all of the syntaxes (except 
> `<<...>>`) have, there are no problems.
>

I'm just quoting the RFC here, then paraphrasing. If you want to know
what "potential problems" #[] introduces for PHP7 code, you'll have to
ask the authors of the RFC.

>> syntaxes we still haven't voted
>> on? Yes!
>> Come on...
>>
>> And lastly...
>>
>> > We argue why we should strongly favor a syntax with closing delimiter to 
>> > keep consistency with other parts
>> > of the language and propose to use #[], @[], or the original << … >> 
>> > instead.
>>
>> This is the only part that contains logically valid arguments, albeit
>> most are subjective and speculative. Which is not to say it's not
>> worth voting on them.
>> But looking for actual facts, I only came across only this little cutie:
>> > For VIM users, the % operation to jump between opening and closing part of 
>> > declaration that would automatically work with [ and ].
>> I fully expect all 3 VIM users to vote in favor of this RFC ;-)
>>
>> Ok, enough of my sarcasm - I only wish you'd put your strongest
>> arguments first and focused on quality over quantity.
>
>
> I wish someone actually gave reasonable arguments as to why `@@` is better. 
> Because a) no one cares if we have to type 2 or 3 characters b) `@@` does not 
> ensure 100% safe future c) it does not decrease complexity in any way.
>

@@ already won the vote. The burden of proof for superseding the
popular vote should be on the RFC authors. But for the record, I
visually and mentally like all the examples with @@ more than their
block-syntax counterparts. As I said previously; without hard facts,
it's just a subjective matter. If I'm a weirdo for actually liking @@
I'm not sorry :-D

Best,
Jakob

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benas IML]

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 ending delimiter and thus, we will run
> > into parsing issues.
>
> Both @{} and @@{} would be possible as a future extension of the syntax
> and would have no BC break at all, if extending the syntax is something
> that would/should happen - just as possible suggestions.


Introducing `@@{}` would:
* be against `@@` "conciseness" ideology and would be longer than
`@[]`/`#[]`
* what's the point of creating a new syntax if we can just pick `@[]`/`#[]`?


> It is likely though that the vast majority of attribute usage will be
> quite simple (like the ones we have today with annotations: for routes,
> for validation, for ORMs), so having a simple syntax for a feature which
> is mostly used in a straightforward way does not seem that crazy.
>

"It is likely" is key here. So far, the only "positive" thing I have seen
about `@@` is smaller BC break which is albeit questionable since I was
able to find only 2 instances of a BC break for `@[]` (when searching top
Composer packages).

As for other "pros", let's be honest, no one cares that `@@` is 2
characters whereas `@[]` is 3 characters.


> And about your condescending remark of people trying to add to the
> discussion who have not "proven themselves in the PHP source code":
> Having a discussion with people who have different viewpoints seems like
> a big benefit for any project, because it is impossible to be an expert
>

At the end of the day, the so called "experts" are maintaining PHP source
code.

Having an opinion is okay but being ignorant about the issues which might
arise to the maintainers is completely unacceptable.

at C code, php-src, PHP code, all PHP frameworks, all the PHP libraries,
> and all the ways PHP is used today - yet all that can be relevant for
> language changes and the actual usage of new features, including the
> syntax.
>

Best regards,
Benas

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Jakob Givoni]

On Tue, Aug 18, 2020 at 12:36 AM Mike Schinkel  wrote:
>
> I have been following all the lengthy discussions on this topic hoping the 
> list would come to consensus. And I had been hoping someone would call the 
> following question but since no one else has here goes.
> [...]
>
> Should we not:
>
> 1. Postpone inclusion of attributes until PHP 8.1 to ensure that we get a 
> syntax that is reasonable acceptable to large segment of stakeholders?
>

Seems prudent to me.

> 2. Optionally have an RFC to ask people to vote on disputed principles, such 
> as "Are ending delimiters important and thus are they required for any 
> selected syntax?"
>

+1  (I already suggested this)

> 3. Then open up the floor for more syntax proposals (that address all the 
> accepted principles in #2) in hopes to find something generally acceptable to 
> a larger segment of stakeholders with a goal of completing by 8.1?
>

Preferable something without square brackets :-p


But it's hard to go the decent, albeit longer, path when you can
almost smell the short term victory already.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Mike Schinkel]

> On Aug 18, 2020, at 6:54 AM, Benjamin Eberlei  wrote:
> 
> On Tue, Aug 18, 2020 at 12:36 AM Mike Schinkel  > wrote:
> I have been following all the lengthy discussions on this topic hoping the 
> list would come to consensus. And I had been hoping someone would call the 
> following question but since no one else has here goes.
> 
> The concept of adding attributes to PHP seemed to sail to acceptance but, if 
> you count the original RFC there have been three (3) different RFCs each with 
> the goal of setting or changing the decided syntax alone.
> 
> For every syntax proposed there seems to be a contingent of people who are 
> deeply troubled by it. Given that once a syntax lands in an official release 
> of PHP there are not take backs, moving forward with any syntax where people 
> are so divided seems like a really bad idea. 
> 
> If we care about future developers being happy enough with the decisions made 
> about PHP to continue choosing PHP that I would think it would be incumbent 
> upon us to find a syntax with a greater level of buy-in.
> 
> Should we not:
> 
> 1. Postpone inclusion of attributes until PHP 8.1 to ensure that we get a 
> syntax that is reasonable acceptable to large segment of stakeholders?
> 
> All the technically complex decisions are done, tested and decided. The 
> syntax question is still open, but not critical from a technical 
> implementation POV. All patches regardless of syntax are extremely similar, 
> just replacing symbols. The non-technical implications and future related 
> questions are what is up for decision. The arguments for or against these 
> categories are by now driving in circles. Postponing to 8.1 does therefore 
> not bring additional value. A decision has to be made and we have enough time 
> for that.
> 
> 2. Optionally have an RFC to ask people to vote on disputed principles, such 
> as "Are ending delimiters important and thus are they required for any 
> selected syntax?"
> 
> By voting for a syntax, these questions are answered implicitly.

Then may I please be allowed to add another option (or two) to the RFC, in 
hopes that it will be disliked less by everyone that the level of dislike a set 
of people have for every option?

I propose we utilize the "use" command but with required parenthesis using 
examples from my code where I previously simulated attributes:

// class attribute use
use PostType('abc_product'),
   TemplateVariable('product'),
   VirtualReadonly('id'),
   VirtualReadonly('name');
// method attribute use
use PrimaryKey();
An option to the above is we utilize the "use" command w/o required parenthesis 
but w/attribute modifier, although this is not my preference:
// class attribute use
use attribute PostType('abc_product'),
   TemplateVariable('product'),
   VirtualReadonly('id'),
   VirtualReadonly('name');
// method attribute use
use attribute PrimaryKey;
I have prepared a longer example as a Gist:

https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8 


Appropriateness
-

The second option is similar to "use function " so while it is not exactly the 
same, "use" is utilized by three contexts already, two (2) of them w/o a 
modifier:

1.) providing a local name for a namespace,
2.) providing a local name for a function, and 
3.) what is effectively an include() for a trait. 

The semantics of "use" works for attributes — i.e. "Use this attribute for the 
following declaration" — and having a 4th type of use seems like it would fit 
nicely into the existing language.

I would suggest viewing all the different syntaxes to see who "use AttrFunc()" 
compares in terms of readability:

https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8 


Benefits
---
1. Short; three (3) characters that — importantly — DO NOT require use of the 
shift key (which my carpal tunnel would be thankful for.). 

1a. The 2nd options should be easy to type with an IDE/editor that 
supports macros
1b. For example in PhpStorm you could assign ua to expand to "use 
attribute "

2. Has a closing delimiter, the semi-colon.

3. Supports grouping, using commas just like other uses of the "use" command.

4. Forward compatible in PHP 7 (I think.)

5. Uses existing T_USE attribute.

6. (I do not know if it would change the lexing of remaining tokens)

7. Does not prevent the nesting of attributes in the future as braces could be 
used as they currently are with traits

-Mike

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

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 excemption from the RM Sara as per [2]:
>
> > * Shorter Attribute Syntax Change
> >- Joe/Derick - Please make sure this RFC moves along and reaches
> >  conclusion by beta3, as discussed previously.
>
> Heads up: This RFC is now going to vote tomorrow:

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 too narrow and ultimately not
that important as downstream libraries just have to deal with any of it
- some more nuances in forward compatibility pro/cons section of #[]
- smaller corrections and improvements.

I don't think something major is missing now.


>
> cheers,
> Derick
>
> [1] https://externals.io/message/111218#111261
> [2] https://externals.io/message/111286#111286
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Tue, Aug 18, 2020 at 8:49 AM Aleksander Machniak  wrote:

> On 18.08.2020 00:35, Mike Schinkel wrote:
> > 1. Postpone inclusion of attributes until PHP 8.1
>
> +1
>
> I wonder why my suggestion (somewhere in this thread) didn't get any
> attention. Is it because the ship had sailed or it's a terrible idea?
>

A suggestion requires a patch, otherwise it's just theoretical.

One problem I see with your suggestion is the conflict in a code like this:


> declare(
> SomeAttr,
> AnotherAttr("Hello world")
> )
> function someFunc() {
> }
>
> It's almost identical to #[] or @[], but it looks like PHP and has no BC
> breaks. To me it also sounds good - "declare attribute(s) [for] something".
>
> ps. sorry Mike for a duplicate, I pressed the wrong button.
>
> --
> Aleksander Machniak
> Kolab Groupware Developer[https://kolab.org]
> Roundcube Webmail Developer  [https://roundcube.net]
> 
> PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] FFI Improvements: Consistency and soliving some problems

[Dan Ackroyd]

On Thu, 9 Jul 2020 at 09:01, Dan Ackroyd  wrote:
>
> On Mon, 6 Jul 2020 at 22:37, Кирилл Несмеянов  wrote:
> >
> > I would like to start discussion about the «FFI Improvements» RFC. At the 
> > moment, I do not have the right to create wiki page, so I post it on the 
> > github:  
> > https://github.com/SerafimArts/php-rfcs/blob/ffi-improvements/rfcs/-ffi-improvements.md
> >
>
> For FFI_LIB, FFI_SCOPE, and FFI_LIB_DIR your proposal sounds sensible.
> It would be really good if someone involved in getting FFI into core
> could comment if there was any specific reason for not doing that
> already.

It's too late for PHP 8.0 but it would still be good to hear from
anyone who knows about the choices made for FFI, so that it can be
improved.

Otherwise should we start considering whether the FFI stuff is an
experiment that is not being supported?

cheers
Dan
Ack

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Morel]

On Tue, 18 Aug 2020 at 08:49, Aleksander Machniak  wrote:

>
> I wonder why my suggestion (somewhere in this thread) didn't get any
> attention. Is it because the ship had sailed or it's a terrible idea?
>
> declare(
> SomeAttr,
> AnotherAttr("Hello world")
> )
> function someFunc() {
> }
>

This syntax has its benefits, but IMHO looks a bit clumsy for simple
annotations, and does not make it stand out as an annotation to my eyes:

declare(Inject)
class Foo {
}

But this may be just me.

— Benjamin

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[David Rodrigues]

I really found your idea better than all. Keywork is already reserved, make
sense on this context.

Em ter, 18 de ago de 2020 03:49, Aleksander Machniak 
escreveu:

> On 18.08.2020 00:35, Mike Schinkel wrote:
> > 1. Postpone inclusion of attributes until PHP 8.1
>
> +1
>
> I wonder why my suggestion (somewhere in this thread) didn't get any
> attention. Is it because the ship had sailed or it's a terrible idea?
>
> declare(
> SomeAttr,
> AnotherAttr("Hello world")
> )
> function someFunc() {
> }
>
> It's almost identical to #[] or @[], but it looks like PHP and has no BC
> breaks. To me it also sounds good - "declare attribute(s) [for] something".
>
> ps. sorry Mike for a duplicate, I pressed the wrong button.
>
> --
> Aleksander Machniak
> Kolab Groupware Developer[https://kolab.org]
> Roundcube Webmail Developer  [https://roundcube.net]
> 
> PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Tue, Aug 18, 2020 at 12:36 AM Mike Schinkel  wrote:

> I have been following all the lengthy discussions on this topic hoping the
> list would come to consensus. And I had been hoping someone would call the
> following question but since no one else has here goes.
>
> The concept of adding attributes to PHP seemed to sail to acceptance but,
> if you count the original RFC there have been three (3) different RFCs each
> with the goal of setting or changing the decided syntax alone.
>
> For every syntax proposed there seems to be a contingent of people who are
> deeply troubled by it. Given that once a syntax lands in an official
> release of PHP there are not take backs, moving forward with any syntax
> where people are so divided seems like a really bad idea.
>
> If we care about future developers being happy enough with the decisions
> made about PHP to continue choosing PHP that I would think it would be
> incumbent upon us to find a syntax with a greater level of buy-in.
>
> Should we not:
>
> 1. Postpone inclusion of attributes until PHP 8.1 to ensure that we get a
> syntax that is reasonable acceptable to large segment of stakeholders?
>

All the technically complex decisions are done, tested and decided. The
syntax question is still open, but not critical from a technical
implementation POV. All patches regardless of syntax are extremely similar,
just replacing symbols. The non-technical implications and future related
questions are what is up for decision. The arguments for or against these
categories are by now driving in circles. Postponing to 8.1 does therefore
not bring additional value. A decision has to be made and we have enough
time for that.

>
> 2. Optionally have an RFC to ask people to vote on disputed principles,
> such as "Are ending delimiters important and thus are they required for any
> selected syntax?"
>

By voting for a syntax, these questions are answered implicitly.

>
> 3. Then open up the floor for more syntax proposals (that address all the
> accepted principles in #2) in hopes to find something generally acceptable
> to a larger segment of stakeholders with a goal of completing by 8.1?
>
> -Mike
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Better string interpolation

[Rowan Tommins]

Hi Ilija,

On Mon, 17 Aug 2020 at 18:54, Ilija Tovilo  wrote:

>
> sprintf-style modifiers are an interesting idea. But I'm not sure if
> there would be a huge advantage over using number_format.
>
> [...]
>
> Escaping is a nice idea but I'm not sure we want to go that route.
> String interpolation is still a bad fit for many templating things...
>


The above reactions basically mirror my initial reaction to your initial
e-mail: an extended string interpolation feature sounds nice, but how does
it differ from string concatenation and function calls? That's why I
started thinking about additional features to bring in: I was trying to
think of the use cases this new syntax would be for, and what new things it
would make possible (or rather, easier).

If the proposal is to add a completely new string syntax, I feel like it
needs a stronger justification than being able to write $"Hello
#{Foo::bar()}\n" rather than "Hello " . Foo::bar() ."\n"

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Jordi Boggiano]

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 userland token stream scanners myself, and it's
not difficult to skip `T_WHITESPACE` and `T_COMMENT` tokens. Once you do
that, parsing an attribute is as simple as finding any `T_ATTRIBUTE`
token followed by the name token, then checking for an optional
argument list. If there's not an argument list, that's then end of
the attribute, otherwise the end is the end of the argument list.

With the `@[]` and `#[]` syntaxes, a userland token parser is actually
*more* complex due to grouping. It not only has to do the same things
listed above, but it also has to check whether there are multiple
comma-separated attributes between the start/end delimiters (making
sure not to confuse a comma-separated attribute with a comma-separated
argument, or the end of an array argument with the attribute end
delimiter).

So I don't understand how the RFC can claim that attributes without
an end symbol "introduce additional complexity" for machines, when if
anything the opposite is true.

(And don't get me started about the extra difficulty for token stream
scanners with the `<<>>` syntax which has no `T_ATTRIBUTE` token).


I noticed you did not answer this point at all, I know there are lots of 
emails to reply to but IMO this is quite an important dismissal of one 
of the few technical arguments made for grouping, and also something I 
tried to hint at on Twitter back on Sunday..


Reading the RFC again now, IMO the whole "Machine Scanning for End of 
Attribute Declaration" section should be removed.


From the points left, only "Potential Future Benefits of Enclosed 
Delimiter Syntax" is technically valid but really dependent on what we 
see as interesting future use cases. The rest is rather subjective and 
thus not really worth discussing, it'll be up to everyone's preference.


Best,
Jordi

--
Jordi Boggiano
@seldaek - https://seld.be

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Aleksander Machniak]

On 18.08.2020 00:35, Mike Schinkel wrote:
> 1. Postpone inclusion of attributes until PHP 8.1

+1

I wonder why my suggestion (somewhere in this thread) didn't get any
attention. Is it because the ship had sailed or it's a terrible idea?

declare(
SomeAttr,
AnotherAttr("Hello world")
)
function someFunc() {
}

It's almost identical to #[] or @[], but it looks like PHP and has no BC
breaks. To me it also sounds good - "declare attribute(s) [for] something".

ps. sorry Mike for a duplicate, I pressed the wrong button.

-- 
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php