Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

[Jakob Givoni]

On Wed, Feb 21, 2024, 19:57 Larry Garfield  wrote:

> Hello again, fine Internalians.
>
> After much on-again/off-again work, Ilija and I are back with a more
> polished property access hooks/interface properties RFC.  It’s 99%
> unchanged from last summer; the PR is now essentially complete and more
> robust, and we were able to squish the last remaining edge cases.
>
> Baring any major changes, we plan to bring this to a vote in mid-March.
>

> It’s long, but that’s because we’re handling every edge case we could
> think of.  Properties involve dealing with both references and inheritance,
> both of which have complex implications.  We believe we’ve identified the
> most logical handling for all cases, though.
>
> Note the FAQ question at the end, which explains some design choices.
>
> There’s one outstanding question, which is slightly painful to ask:
> Originally, this RFC was called “property accessors,” which is the
> terminology used by most languages.  During early development, when we had
> 4 accessors like Swift, we changed the name to “hooks” to better indicate
> that one was “hooking into” the property lifecycle.  However, later
> refinement brought it back down to 2 operations, get and set.  That makes
> the “hooks” name less applicable, and inconsistent with what other
> languages call it.
>
> However, changing it back at this point would be a non-small amount of
> grunt work. There would be no functional changes from doing so, but it’s
> lots of renaming things both in the PR and the RFC. We are willing to do so
> if the consensus is that it would be beneficial, but want to ask before
> putting in the effort.
>
> --
>   Larry Garfield
>   la...@garfieldtech.com


Hi, thanks for the RFC and the effort put into trying to make it palatable
to skeptical minds!

After reading most of the discussion in this thread I believe that the RFC
in its current form can work and that I will get used to it's
"peculiarities", but an idea occurred to me that may have some advantages,
so here goes:

Use the "set" keyword that you've already introduced to set the raw value
of a "backed" property:

public int $name {
set {
 set strtoupper($value);
}
}

Or when used in short form:

public int $name {
set => set strtoupper($value);
}

Advantages in no particular order:
1. Shorter than $this->name
2. No magic $field
3. Short and long form works the same

Disadvantage: "Set" can only be used to set the raw value inside the hook
method itself. Or maybe that's a good thing too. To be honest, I don't love
that $this->name sometimes goes through the hook and sometimes not. I'd
prefer if the raw value could only be accessed inside the hooks or via a
special syntax like f.ex. $this->name:raw

If there are any use cases or technical details that I've missed that would
make this syntax unfavourable, I apologize.


Another observation (I apologize for being late to the game but it was a
long RFC and thread to read through):

What would happen if we stopped talking about virtual vs. backed
properties? Couldn't we just treat a property that was never set the same
as any other uninitialized property?
What I mean is, that if you try to access the raw value of a property with
a set hook that never sets its own raw value, you'd get either null or Typed
property [...] must not be accessed before initialization, just like you'd
expect if you're already used to modern php. Of course you'd just write
your code correctly so that that never happens. It's already the case that
uninitialized properties are omitted when serializing the object so there
would be no difference there either.

The advantage here would be that there's no need to detect the virtual or
backed nature of the property at compile time and the RFC would be a lot
shorter.


Thank you for your consideration!

Best,
Jakob

Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1

[Jakob Givoni]

On Tue, Jul 6, 2021 at 10:30 AM Rowan Tommins  wrote:
>
> Hi Mike,
>
>
> > Instead I replied because your email strongly implied (stated?) that 
> > "deprecation required removal"
>
> I stand by that interpretation, which while not universal is very widely
> used, and I think is more useful than a general hint at "bad practice".
>
> You spend most of your e-mail seeming to argue against it, and then seem
> to say that actually you do agree with it after all, and all you're
> saying is that sometimes the deprecation period should be longer:
>
>
> > I am not advocating that.  I am advocating we should consider making it:
> >
> > "features that are strongly discouraged will*probably*  be removed in the 
> > next major version, but in some cases may be retained for one or more major 
> > versions."
>
> I'm totally OK with that.
>
> I do think that there should be a clear *plan* for removing each
> deprecated feature, though. That plan might be "deprecate in 8.1, and
> examine prior to 9.0 whether usage has dropped / the alternatives are
> mature / etc". It might flat out be "deprecate in 8.1, but don't remove
> until 10.0".
>
> Otherwise, the message becomes "this feature is kind of bad, and at some
> point we might decide to drop it without further notice, but actually we
> might not, so no hurry to remove it", which I just think isn't that helpful.
>

I think it would be very helpful.
I would have loved to know that FILTER_SANITIZE_STRING was not
considered a good choice when I recently researched how to improve an
issue.
Deprecation without a fixed removal version is better than no
deprecation (because removal version was not agreed on).

Actually I agree with everything that Mike said previously and I
strongly suggest a policy that looks like this:

Deprecation means no longer encouraged (strongly) and might be removed
in a future (major) version.
Before every new major version, review all deprecated features/usages
and decide with a simple RFC if each of them should be removed,
reviewing the current usage level and migration paths.

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

[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] [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

[Jakob Givoni]

Hi Benas,

On Mon, Aug 17, 2020 at 11:34 PM Benas IML  wrote:
>
> On Tue, Aug 18, 2020, 12:25 AM Jakob Givoni  wrote:
>>
>> The question is now if it's reasonable at all to change something for
>> 99% purely subjective reasons (no other substantial fact has been put
>> forward other than the VIM argument) well past feature freeze (yes I
>
>
> In the future, syntax with an ending delimiter might help us to not run into 
> new parsing issues like `@@` did.
>
> And yes, the future DOES indeed matter. I hate when people who don't 
> contribute to or maintain the php-src actively try to tell otherwise.

I sincerely hope you're not trying to put words in my mouth. Don't be a d*ck.

> Again, in the future we might introduce a new feature that might make
> attributes have more complex parts than just an argument list. In this
> case, `@@` or `@:` is only going to f*** us up.

It sounds like you want to develop a whole new language inside those
attribute blocks... Not sure that's a good idea either, because, you
know, as they say, the future DOES indeed matter ;-)

Regards,
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

[Jakob Givoni]

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 a closing
> delimiter / enclosing syntax.
> - A section on grouping pro/cons
> - Inclusion of @: as per Theodores request
>
> We are looking for further feedback from the community.
>

>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.

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 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.

- Jakob

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

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

[Jakob Givoni]

On Sun, Aug 16, 2020 at 11:32 AM Benjamin Eberlei  wrote:
>
> On Sun, Aug 16, 2020 at 10:39 AM Jakob Givoni  wrote:
>>
>> Hi Benjamin,
>>
>> I'm sorry, but I don't understand your argument.
>> It's true that annotations used to be enclosed in a docblock, but that
>> is not an argument for saying that attributes NEEDS to be enclosed in
>> a block too.
>> It's also true that attributes can be followed by many different
>> things, but still it doesn't follow that block enclosing is NECESSARY.
>> What I'm saying is that there is still no good argument for why
>> attribute block syntax is better than non-block syntax.
>> The only argument that was presented in the original RFC was not
>> convincing, and I pointed out why.
>
> Nobody says it's ultimately **necessarry** as @@ can work.

Thanks for the clarification. This is the first time I've heard
someone from the block-delimiter camp concede that @@ is not
necessarily objectively "terrible" (as you yourself put it almost a
month ago), as it was made out to be.

The question is now if it's reasonable at all to change something for
99% purely subjective reasons (no other substantial fact has been put
forward other than the VIM argument) well past feature freeze (yes I
know it's not a feature, but it's still controversial), even past the
beta3 date. And still without respect for letting the discussion phase
run its course before putting to a vote.

May I remind everybody of a few words long ago from our release manager Sara:

> I'm fine with this or any syntax, but FF is 13 days away, you're going to
> have to give me something more substantial than "It maybe breaks something
> somewhere somehow".

> Regards the vote; I don't believe that @@ has been proven unworkable,
> however if I'm wrong about that, then the second choice selection from the
> last vote would obviously take precedence.

> If that's the case, then the solution still seems obvious: Defer attributes
> to 8.1. I know a LOT of people will not be happy about that, but it's the most
> responsible thing to do if the threat of forking up is that present and
> that dangerous.

How did we end up here? What started with "[...] a deep sense of
unease that we collectively made the
wrong decision [...]" may have taken a turn for the worse when it
comes to confidence in the process and the community.
Or is it just me being dramatic? :-D

All the best,
Jakob

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

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

[Jakob Givoni]

On Sun, Aug 16, 2020 at 1:00 AM Benjamin Eberlei  wrote:
>>
>> The RFC says that
>> > 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 termination symbol.
>> However, it's clear that attributes are neither a declaration nor a
>> statement, but metadata about the thing that follows them (unless it's
>> more attributes or comments).
>> The ultimate proof of this is that a semicolon after an attribute is illegal.
>
> I would like to chime in here since this argument is made over and over 
> again, even though it overlooks an important point. when we say that 
> attributes are just metadata, then let's compare them to docblocks with *are* 
> always enclosed in /** and */ instead of visibility keywords.
>
> This comparison is fair, because doc comments are often multi line and 
> attributes are as well. When doc comments are single line, they are also 
> enclosed.
>
> Whereas a comparison with visibility modifiers that are *just* tokens that 
> *always* are followed by a T_WHITESPACE is apples vs oranges, because @@ 
> attributes can be followed by a large set of different things:
>
> @@Foo @@Bar // ends due to T_WHITESPACE with " "
>  @@Foo // ends due to T_WHITESPACE with "\n"
>  @@Foo() // ends due to )
>  @@Foo () // ends with ), the T_WHITESPACE between class and arguments is 
> valid
>  @@Foo@@Bar // ends due to new T_ATTRIBUTE
>  @@Foo()@@Bar // ends due to )
>  @@Foo
>  ("bar") // ends here in the second line at )
>  function a_function() {
>  }
>

Hi Benjamin,

I'm sorry, but I don't understand your argument.
It's true that annotations used to be enclosed in a docblock, but that
is not an argument for saying that attributes NEEDS to be enclosed in
a block too.
It's also true that attributes can be followed by many different
things, but still it doesn't follow that block enclosing is NECESSARY.
What I'm saying is that there is still no good argument for why
attribute block syntax is better than non-block syntax.
The only argument that was presented in the original RFC was not
convincing, and I pointed out why.
I'm also not saying that non-block syntax is better.
Hence, it seems it's just a matter of taste, so far - unless we get to
see some convincing arguments in the rewritten RFC.

Thanks,
Jakob

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

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

[Jakob Givoni]

>
> Can I make a suggestion?
>
> Make the new or updated RFC a primary vote on: "Should attributes be
> enclosed in delimiters?"

Actually, let's add the word "block" in there:
"Should attributes be enclosed in block delimiters?"

Where block delimiters are "matching" (not interpreted in any strict
way) beginning and ending symbols.
This is in opposition to f.ex. the @@ syntax that does have ending
delimiters (you know that it ends when you find a specific token),
whether they are a closing bracket or a white space.

So the question becomes "block syntax" or "non-block syntax".

Best,
Jakob

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

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

[Jakob Givoni]

>
> We are working to integrate our arguments in favour of enclosing from that 
> Derick and I made in this and the previous thread into the RFC at the moment, 
> as the lack of them is a valid point of criticism.
>
> Additionally, Derick and I are waiting for word from Sara and Gabriel at the 
> moment, but we suggested to close and reset the vote to wait until the 
> discussion period is over on Tuesday to accommodate the criticism of us 
> prematurely starting the vote (by accident, not intentionally). We will take 
> the time to update the RFC with all discussions from here and the previous 
> thread with arguments that have come up.

Can I make a suggestion?

Make the new or updated RFC a primary vote on: "Should attributes be
enclosed in delimiters?"
This is what we're really discussing and that would make the intention
and everything that follows much clearer.
Then the secondary votes can be on the preferred block syntax.
Voting no means to keep @@ (unless there's another RFC for voting to
change that for another syntax without ending delimiter).

We've had two RFC's now that both had the primary vote being basically
"Are you ok to vote?" - A vote on whether or not to vote???
Maybe it's not a coincidence that both results were considered
disasters by a big chunk of voters.

The primary vote should be on the RFC and the RFC should have a clear
intention. Once you vote yes to the RFC as a whole, any secondary
votes should be just details - mostly about "taste" so to speak and
anyone voting yes on the primary vote should be happy to accept any
outcome of any secondary vote. If that's not the case, the RFC
smells...

Cheers,
Jakob

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

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

[Jakob Givoni]

This will probably be my only contribution to this thread so I'll keep
it simple:

Am I in favor of a revote? Yes
Can I vote myself? No
Do I think a revote will change anything? No
Have there been any good arguments for why attributes need an ending
delimiter? No

The RFC says that
> 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 termination symbol.
However, it's clear that attributes are neither a declaration nor a
statement, but metadata about the thing that follows them (unless it's
more attributes or comments).
The ultimate proof of this is that a semicolon after an attribute is illegal.

Do I think attributes need an ending delimiter? No
Would I prefer the @@ syntax? Yes
Do I think @@ is ugly or difficult to type? No
Is it just a subjective matter of personal taste? Yes
Is this whole discussion almost entirely a subjective matter? Yes
Is this email thread, the RFC, the voting and the discussion about
extending it a farce? Yes
Do I mind waiting until 8.1 to have attributes so that it can be done right? No

Godspeed!

Best, Jakob

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

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

[Jakob Givoni]

On Wed, Aug 12, 2020 at 9:08 PM Rowan Tommins  wrote:
>
> On 12 August 2020 19:03:02 BST, Jakob Givoni  wrote:
> >> > Is
> >> >
> >> > 
> >> >
> >> > on it's own an error?
> >>
> >> Yes. Basically this is an example of valid code in PHP 7 that will
> >> break if @[] is adopted.
> >
> >Wow, that was unexpected. By what logic?
> >Also, how long must I wait before I can put a semicolon after the new
> >attribute syntax? Is one whitespace enough or do I have to go to a new
> >line?
> >To me, suddenly disallowing semicolons at some points between
> >statements or between a "declaration" and a statement seems to break
> >PHP logic.
>
>
> It's not that the semicolon is forbidden as such, it's that the code is 
> interpreted completely differently.
>
> Imagine if we had no "private" keyword, and then added it; this would 
> previously have been valid (a statement followed by a declaration):
>
> private; function foo () {}

Ok, that's starting to make sense. Having seen so many attribute
examples lately I started to get the impression that you could
basically insert them anywhere (like comments) - even if it didn't
technically make any sense... Reading the original RFC again I
understand that an attribute MUST be directly followed by a function,
class, interface, traits, class constant, class property, class
method, function/method parameter, a docblock or another attribute. I
hope I didn't forget anything... Sorry, I'm just a sucker for details
and accuracy :-)

Thanks,
Jakob

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

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

[Jakob Givoni]

On Tue, Aug 11, 2020 at 3:03 PM Theodore Brown  wrote:
>
> On Tue, Aug 11, 2020 at 7:26 AM Chris Riley  wrote:
>
> > On Tue, 11 Aug 2020 at 13:21, Derick Rethans  wrote:
> >
> > > On Tue, 11 Aug 2020, Chris Riley wrote:
> > >
> > > > Quick question.
> > > >
> > > > What is the expected behaviour of:
> > > >
> > > > @[Bar()];
> > > > class Foo {}
> > >
> > > That will error out in PHP 8, with:
> > >
> > > Parse error: syntax error, unexpected token ";" in Standard input code on
> > > line 2
> >
> > Is
> >
> > 
> >
> > on it's own an error?
>
> Yes. Basically this is an example of valid code in PHP 7 that will
> break if @[] is adopted.

Wow, that was unexpected. By what logic?
Also, how long must I wait before I can put a semicolon after the new
attribute syntax? Is one whitespace enough or do I have to go to a new
line?
To me, suddenly disallowing semicolons at some points between
statements or between a "declaration" and a statement seems to break
PHP logic.

Are there any precedents for this that I've missed?

Best,
Jakob

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

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Jakob Givoni]

On Thu, Jun 18, 2020 at 9:39 AM Nikita Popov  wrote:
>
>> In a mail that probably went to everyone's spam folder, I asked for
>> opinions on allowing use of .\Foo as an alternative to Foo in the
>> current namespace, thus reducing friction with reserved keywords even
>> more. Any thoughts on that now?
>
>
> How would .\Foo be different from the currently existing namespace\Foo? (Note 
> that "namespace" here is to be taken literally, not as "put the current 
> namespace here").
>

I didn't know you could do that! I don't think I've ever seen it used,
maybe because there's been little advantage over just Foo? I guess it
only matters if you also import Foo?
For what it's worth, .\Foo would be significantly shorter than
namespace\Foo and probably more intuitive to understand as well.
Furthermore, if you were to create a namespace called "Namespace"
(don't judge! ;-)), which I would assume would be possible should this
RFC be implemented, we could avoid namespace\Namespace\Foo :-D

Thanks for the feedback, it was just an idea - could be a new RFC some
other day.

Thanks,
Jakob

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

Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

[Jakob Givoni]

On Wed, Jun 17, 2020 at 4:22 PM Chase Peeler  wrote:
>
> Please stop using the term "glob." As a person that is above what many
> would consider an ideal weight, I've been called a "useless glob" on
> multiple occasions. This term is harmful to me as a result.
>

Though I know you're joking (and I laughed out loud!) I think you are
misunderstanding something:
Calling someone black is actually not offensive!
To repeat what has been said many times over now: It's when "black" is
associated with "bad" in a composite term like "blacklist" we should
consider being considerate of a group of people who actually have skin
of that color.
If we, hypothetically, happened to be using the term "obeselist" (for
whatever obscure historical reason) to mean "list of things to be
blocked", would you also think that was totally fine because context
is everything and nobody's saying you're worth less because you're
overweight?

Best,
Jakob

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

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Jakob Givoni]

On Tue, Jun 16, 2020 at 10:52 AM Nikita Popov  wrote:
>
> Hi internals,
>
> Inspired by the recent discussion on reserved keyword reservation, I'd like
> to propose the following RFC:
>
> https://wiki.php.net/rfc/namespaced_names_as_token
>
> This RFC makes two related changes: Treat namespaced names as a single
> token, which enables use of reserved keywords inside them. And remove
> reserved keyword restrictions from various declarations.
>
> The RFC comes with a small backwards compatibility break related to names
> that include whitespace, but will hopefully reduce the backwards
> compatibility impact of future reserved keyword additions.
>
> Regards,
> Nikita

Love it, thanks Nikita!

In a mail that probably went to everyone's spam folder, I asked for
opinions on allowing use of .\Foo as an alternative to Foo in the
current namespace, thus reducing friction with reserved keywords even
more. Any thoughts on that now?

Best,
Jakob

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

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

[Jakob Givoni]

On Mon, Jun 15, 2020 at 6:49 PM Michael Cordover  wrote:
>
> The black in black hole and the white in whitespace are descriptions of the 
> actual colors of these things.
> There's no value judgement there.
> Blacklist, on the other hand, is explicitly making a judgement that things on 
> that list are bad.
> The association of "black" with "bad" (and "white" with "good" in whitelist) 
> is the problem, not merely the use of a color at all.

Yes, someone who gets it.

I am using the term "blacklist" often in the project I work on, and it
never occurred to me before that it could be considered offensive.
But I learned something new in this thread and I am thankful for that!

Best,
Jakob

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

Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Jakob Givoni]

On Thu, Jun 11, 2020 at 12:14 AM Sara Golemon  wrote:
>
> You know what shows up unambiguously in a google search? "Paamayim
> Nekudotayim".
> You know what ISN'T unambiguous in a google search? "Double Colon"

Straw man. The point being that you wouldn't have to Google "Double
Colon" because it is self explanatory.

> Token names shouldn't show up.  Everyone is agreeing with that statement.
> Universally.  Let's fix that problem rather than create new ones by not
> addressing the underlying issue.

Are you saying that this RFC is creating a new problem? If so, please elaborate.

>
> Once again I plead for logic and sanity. At least have the courage to put
> > it to a vote.
> >
> > Absolutely. Put it to a vote.  I've got my "no" all locked and loaded.

Why is this even an RFC? It's not a language change.
There seems to be consensus that those tokens should not be exposed in
error messages, so changing the name of one is not even a bugfix, it's
just an internal maintainability fix ;-)

If your position is "if it ain't broke, don't fix it", I think the
prudent thing to do would be to abstain from voting. If a change is
perceived as positive for at least one person and the rest are
indifferent, it's still a net positive change.

If your position is "error messages that you have to Google are better
than those you don't" then we should be seeing much more RFC proposing
to rename things like T_STRING to T_EMAFAI_ONAFAI_SAUKOFE etc. :-D

Best regards,
Jakob

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

Re: [PHP-DEV] Avoid ending up in Spam

[Jakob Givoni]

Hi, having relaxed the DMARC rules, please let me know if this message
was more successful than those previously sent from ja...@givoni.dk
Thanks!

On Sat, May 30, 2020 at 1:20 AM Ben Ramsey  wrote:
>
> > On May 29, 2020, at 18:01, Reindl Harald  wrote:
> >
> >
> >
> > Am 30.05.20 um 00:58 schrieb Ben Ramsey:
> >>> On May 29, 2020, at 17:34, Jakob Givoni  wrote:
> >>>
> >>> On Sat, May 30, 2020 at 12:07 AM Benas IML  
> >>> wrote:
> >>>>
> >>>> Here's a quote from Ben Ramsey that basically sums up the problem:
> >>>>
> >>>>> This appears to be happening due to DMARC rules on the domains of the 
> >>>>> senders.
> >>>>> I had the same thing happen to my emails, so I had to relax my DMARC 
> >>>>> rules. If
> >>>>> your rules are set too strict, servers see the From address coming from 
> >>>>> a
> >>>>> server not authorized by the domain, so it gets quarantined.
> >>>>
> >>>
> >>> Shouldn't I just be able to add lists.php.net or something to my SPF
> >>> record for my domain then?
> >>
> >>
> >> That might work. I haven’t tried it. I’ll try to look into it next week 
> >> and see what I can figure out.
> >
> > how do you imagine that a SPF for any random domain could affect
> > envelope senders ending with "@lists.php.net"?
> >
> > DMARC is not just about SPF
> > SPF is not about "From address" in the From-Header
>
>
> I thought SPF allowed you to specify domains/IPs that are allowed to send 
> email “from” your domain.
>
> Why wouldn’t something like this help?
>
> v=spf1 include:_spf.google.com include:lists.php.net ~all
>
> (In this example, assuming one already has an SPF record allowing Google Apps 
> to send email for their domain.)
>
> Cheers,
> Ben
>

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

Re: [PHP-DEV] Avoid ending up in Spam

[Jakob Givoni]

On Sat, May 30, 2020 at 12:07 AM Benas IML  wrote:
>
> Here's a quote from Ben Ramsey that basically sums up the problem:
>
> > This appears to be happening due to DMARC rules on the domains of the 
> > senders.
> > I had the same thing happen to my emails, so I had to relax my DMARC rules. 
> > If
> > your rules are set too strict, servers see the From address coming from a
> > server not authorized by the domain, so it gets quarantined.
>

Shouldn't I just be able to add lists.php.net or something to my SPF
record for my domain then?

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

[PHP-DEV] Avoid ending up in Spam

[Jakob Givoni]

Hi internals,

Sorry for the off-topic, but I need to ask you on this list, how do you
guys avoid having your emails ultimately ending up in the spam folders of
the mailing list recipients?

I had troubles in the past so now I'm using this new gmail account as
someone suggested, hoping you will at least see this message.
Is it true that there's no other solution than using gmail?

Best regards,
Jakob Givoni

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Jakob Givoni]

On Fri, May 22, 2020 at 5:28 PM Nikita Popov  wrote:
>
> I don't particularly care what namespace the attribute classes are under,
> just that they should have a common namespace, because there's going to be
> many of them, presumably. If it was just a matter of the Attribute class,
> I'd definitely say this belongs in the global namespace, but that's not
> what we're dealing with at this point.
>

You've made a really good argument for the \Php namespace here.
I get that PHP reserves the global namespace, but I'm pretty certain
that if PHP ever needs any subspaces, they should be under a common,
non-global, namespace.

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

[PHP-DEV] Reserved words and class name collisions

[Jakob Givoni]

Hello,

It's a common thing to want to introduce a new keyword as a reserved
word as part of an RFC.
(Recently: match, mixed, guard, readonly...)

These new keywords always lead to possible BC breaking changes because
they become unusable for namespaces, class names, function names and
global constants.

This may sound frivolous, but has it been considered to try to find a
way to make it possible to have some classes of language keywords and
identical class names etc. living side by side?

One thing I could think of is to allow prefixing either new keywords
or conflicting class names with a special character whenever there is
a possibility of ambiguity in the syntax.

Let's take an example - I've always wanted to name a class "Function"
:-) It would live in a namespace, f.ex. \App\Middleware\Function. I
don't really see how declaring the class Function or using the fully
qualified class name could be an insurmountable obstacle to
distinguish from the keyword used to declare a function.
However, if you're already in the \App\Middleware namespace and just
find the untethered Function in the code, that would not be nice to
the parser. But if we prefixed it with .\Function the confusion would
evaporate, wouldn't it?

This idea would not eliminate this kind of Backward Incompatible
Changes but the upgrade path to simply prefix the class name etc. with
.\ or something else, whenever it was found out and alone, would cause
a lot less friction that renaming files and classes. And as such it
just might lead to more, otherwise nice RFC's being accepted :-)

If this sparks some interest, let me know. Or rather, tell me please
in a mild tone why this would be a total disaster.

Best regards,
Jakob

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

Re: [PHP-DEV] [DECLINED] match expression RFC

[Jakob Givoni]

On Sat, May 9, 2020 at 6:08 PM Ilija Tovilo  wrote:
>
> I will take the next few days to think
> about how to move forward.
>

Hi Ilija,

Have you thought about what you'll do next?

I think the part about introducing "match" as an alternative to
hashmaps and nested ternaries is a no-brainer - there seemed to be
pretty good support for that.

Regarding an actual alternative to the horrible "switch", maybe we can
introduce it using "case/when" like in SQL?

If you're sure you're not going to pursue one of these options, maybe
let us know, so someone else can give it a go based on your excellent
work and while it's still fresh :-)

Best,
Jakob

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

Re: [PHP-DEV] Graceful timeout

[Jakob Givoni]

On Sat, 16 May 2020 at 19:42, David Rodrigues 
wrote:

> Hello!
>
> Currently we can use set_time_limit() to specify that our script will run
> by some seconds before we get "fatal error: maximum execution time of 1
> second exceeded". And we can't catch it and keep running.
>
> I believe that it is interesting to create a function that is able to limit
> processing and stop when the time limit is recovered.
>
> $completeRun = set_time_limit_callback(function () {
> sleep(2);
> }, 1);
>
> var_dump($completeRun);
>
> Where $completeRun will be TRUE only if callback could run until it
> returns, and FALSE if timeout.
>
> It should be very useful when we need works with external resources, like
> RESTful, where timeout can occur and we need a better way to work with
> that. Or when we have few seconds to run a process.
>
> What do you think?
>
>
> Atenciosamente,
> David Rodrigues


Hi David!

So you’d like to be able to set a simple timeout on any function call.
I was able to do that with register_tick_function (first time I heard about
it!) with a function that throws an exception when the time’s up and then
surrounding the function call in try/catch.

This could probably be turned into a userland “library”.
I’m not sure how well it would work with real world code though. For sure,
timeouts on http calls must be set on the client handler itself.

Best,
Jakob

>
>

Re: [PHP-DEV] SPL development interest

[Jakob Givoni]

Thank you guys for your insights!

You pretty much confirmed my fears about the SPL extension.

The reason I was wondering about it was mostly for understanding where
one would put Classes, Interfaces and Traits that should be essential
parts of the language.
F.ex. it seems the Countable interface should have been in the core
together with Traversable and Serializable, especially since count()
knows about Countable and is part of the core.

It seems there are only 3 classes that are part of the core: Closure,
Generator and WeakReference.
And no traits, right?

Anyway, thanks again, I'm learning.
Jakob

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

Re: [PHP-DEV] [RFC] Guard statement

[Jakob Givoni]

On Sat, May 16, 2020 at 11:14 AM Pavel Patapau  wrote:
>
> Hello everyone,
>
> I want to propose new syntax addition - guard statement, that executes
> code only if expression equals false and must contain control-flow
> changing code, and written a respective RFC:
>
> https://wiki.php.net/rfc/guard_statement
> 
>
> Implementation in progress.
>
> I started work before this proposal https://externals.io/message/110107
> and respected some moments in the RFC.
>
>
> Thanks for consideration,
> Pavel
>

Hi Pavel,

My feeling about this is that simply adding the "guard" keyword to be
able to write an "negated if" and further requiring certain stuff to
be found in the body statement (which does not sounds trivial) is not
worth the added weight.

I found the inverse "if" construct (return/break/continue/exit/throw
[...] if [...]) that was discussed in the thread as well to be more
interesting, potentially adding something new and flavourful to the
language. However, since I am very much opposed to methods with
multiple return statements, I would probably only use it in the throw
version for defensive programming.

Best,
Jakob

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

[PHP-DEV] SPL development interest

[Jakob Givoni]

Hi Internals,

SPL is an extension that is always available in PHP.
It provides some classes, interfaces and functions etc. such as
- ArrayObject class
- Countable interface
- iterator_count function

What I'd like to wrap my head around is the position of this extension
in PHP and the sentiments towards SPL from the Internals developers.

- What is the status of this extension currently? Is it being actively
developed or just supported?
- Is there any interest in adding stuff here - f.ex. new classes,
interfaces or traits?
- And technically, how is something like ArrayObject class
implemented? And should you implement it again, would it be done the
same way?

Thanks for your time,
Jakob

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

Re: [PHP-DEV] Deprecating uniqid()

[Jakob Givoni]

On Sun, May 3, 2020 at 2:57 PM Rowan Tommins  wrote:
>
> A common suggestion is to use binhex(random_bytes($desired_length / 2)),
> which isn't particularly elegant, and in my experience, the main
> requirement is "a unique string of printable/alphanumeric characters, so
> limiting to [0-9a-f] is just limiting entropy for no reason.
>

Yes, a base_convert(..., 16, 32) around that would help but I'd really
prefer a simple function than a chain of 3 functions (even if we had
Larry's pipe operator :-p)

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

Re: [PHP-DEV] Deprecating uniqid()

[Jakob Givoni]

On Sat, May 2, 2020 at 9:58 PM Nikita Popov  wrote:
>
> On Sat, May 2, 2020 at 9:13 PM Ben Ramsey  wrote:
>
> > > On May 2, 2020, at 13:57, AllenJB  wrote:
> > >
> > > Hi all,
> > >
> > > I'd like to discuss deprecating uniqid()
> > >
> > > I believe it's dangerously bad a doing "what it says on the tin". New
> > developers still reach for it and do not read the warnings on the manual
> > page (or if they do, don't fully understand how bad it is).
> > >
> > > For older codebases that still rely on it, a userland replacement can be
> > easily implemented (and could be published on Packagist).
> > >
> > > I noticed there was an RFC [0][1] brought up 2 years ago, but was never
> > voted on. Does anyone know why this was?
> > >
> > > [0] https://externals.io/message/102097
> > > [1] https://wiki.php.net/rfc/deprecate-uniqid
> > >
> > > Is there interest in deprecating this function?
> > >
> > > If not deprecation, how could it be (further) "improved"? My first
> > thought is to make the "more entropy" option enabled by default (the
> > argument could remain so that it can be disabled by codebases that rely on
> > the lower length and can take the tradeoffs).
> >
> >
> > Instead of deprecating and removing it, would anyone be opposed to
> > replacing the internals of the function so that it uses `random_bytes()`
> > under the hood, while all other functionality remains the same?
> >
>
> I believe this has been discussed in the past, and the basic problem is
> that uniqid() currently only returns 13 hex characters, so we can encode at
> most 52 bits of entropy without changing the output format. This is
> insufficient. Changing the format could break assumptions, such as database
> column sizes.
>
> Personally, I would be in favor of deprecating the function. I've run into
> an issue caused by non-unique uniqid() somewhat recently myself as well.
>
> Regards,
> Nikita

I'm using this function frequently, but I am ok with deprecating it as
I think the name is dangerously misleading - basically, anything that
mentions "unique" without saying to what, is a misnomer.
However, as it's useful to have a function in core that gives you a
random string with a fixed length that is unique within some
well-defined boundaries, I'd like to be sure there is an easy
replacement for the function when the time comes to upgrade php.
Ideally something that is guaranteed to be unique within the current
php process and takes the same arguments as uniqid.

Best,
Jakob

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

Re: [PHP-DEV] [DISCUSSION] Match expression

[Jakob Givoni]

Hi Ilija,

On Sun, Apr 12, 2020 at 2:16 AM Ilija Tovilo  wrote:
>
> I'd like to announce the match expression RFC that replaces the switch
> expression RFC I announced a few weeks ago.
> New: https://wiki.php.net/rfc/match_expression
> Old: https://wiki.php.net/rfc/switch_expression

I know I'm a little late to the game and sorry for that, but I didn't
have time to thoroughly read the proposal earlier.

And again, sorry if it's just me going "blind" but I can't find
anything explaining what will happen if there is more than one
matching arm?

I imagine that since the case of no matching arms will throw an
UnhandledMatchError exception, having several matching arms will also
complain that something looks wrong?

However, that will require all the arms to be evaluated every time,
even after a match is found, which might not be the most optimal
approach.

Then again, if not all arms might be evaluated, the order of
evaluation is important (since several matching arms could be found),
but it's not stated in the RFC if the order of evaluating arms follows
the order they are written, or if the compiler/interpreter is allowed
to choose another order if it thinks it might find the matching arm
sooner?

---

To recap, perhaps you can answer these questions clearly in the RFC:
- What happens if more than one arm is matching?
- In which order are the arms evaluated (in case order is significant)
- is it predictable or an implementation detail that the developer
should not rely on?
- Can the left side of the arms be any expression or only
"constant-style"? (If expressions are allowed, order also becomes
significant)

Apart from these questions, it might be a good idea to evaluate the
impact of the Backwards Incompatible Changes by checking top
repositories for the use of the new keyword "match" in classes and
namespaces etc.

Finally, I find the mixing of match as expression and match as
stand-alone statement unfortunate. I understand very well the
closeness between the two, but I also think that those are two quite
different use-cases which presume different intentions and
expectations for behavior:

For example, when using "match" as an expression and assigning the
value to a variable (the second example at the top of the RFC - as an
alternative to hash maps and nested ternary operators) it's natural to
assume that one and exactly one arm must match. Otherwise the variable
will end up with an ambiguous or undefined value.
I also would consider it "flippant" and not a common need to use block
statements as the arms in this case!

On the contrary, when using "match" as a statement (much more like
"switch" and like "if"), there is no problem if no arms match, and if
several arms match, why not execute all of them? Also, block
statements in the arms would be natural and common.

Would it be a possibility to separate the two into different RFC's?
Personally I find the expression style most useful and I'd be happy to
see this part passed, which I think would be relatively easy since a
lot of the more complex points could be evaded: Block statements,
return statements, break/continue statements (which I don't really
understand in the context of an expression) and the trailing semicolon
issue.

Hope the feedback was useful and best of luck with the RFC!

Jakob

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

Re: [PHP-DEV] [VOTE] Compact Object Property Assignment

[Jakob Givoni]

Voting is over and the RFC has been declined.

Thank you for your participation.

Hope to see some progress on the Constructor Argument Promotion and
Named Parameters projects soon instead :-)

Best,
Jakob

On Tue, Mar 31, 2020 at 1:49 PM Jakob Givoni  wrote:
>
> Heads up!
>
> I've moved the RFC to the voting phase:
>
> https://wiki.php.net/rfc/compact-object-property-assignment
>
> Voting is open until the end of Monday, April 13 (your time zone :-).
>
> Good night,
> Jakob

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

Re: [PHP-DEV] Resurrecting named parameters

[Jakob Givoni]

On Tue, Apr 7, 2020 at 2:45 PM Nikita Popov  wrote:
>
> ## LSP checks for parameter names
>
> Parameter names currently have no particular significance in PHP, only
> their position in the signature is important. If named parameters are
> introduced (in a way that does not require opt-in at the declaration-site),
> then parameter names become significant. This means that changing a
> parameter name during inheritance constitutes an LSP violation (for
> non-constructor methods). There are a number of ways in which this issue
> may be approached:
>
> 1. Silently ignore the problem. No diagnostic is issued when a parameter
> name is changed during inheritance. An error exception will be thrown when
> trying to use the (now) unknown parameter name.

I prefer this approach. It might seem inelegant at first but I believe
none of the other options will do us any real favors, especially
stronger LSP enforcement on the language level. And opt-in seems like
a non-starter for reasons Rowan Tommins lay out (though he's in favor
:-)
Dev side tools will be fully able to "deal" with the downfall.

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

Re: [PHP-DEV] Understanding RFC attitudes

[Jakob Givoni]

Great doc Dan, hope it can be linked from https://wiki.php.net/rfc/howto !
Cheers,
Jakob

On Fri, Apr 3, 2020 at 6:46 PM Chase Peeler  wrote:
>
> On Fri, Apr 3, 2020 at 12:38 PM Dan Ackroyd  wrote:
>
> > Hello Internals,
> >
> > The trade-offs that are good for a project like core PHP are quite
> > different from the trade-offs from other projects.
> >
> > People are sometimes quite surprised by the attitude other people have
> > on how best to maintain and improve PHP.
> >
> > I'm hoping that documenting my understanding of the attitudes that
> > have been taken during RFC discussions, might avoid some of the
> > surprise factor in discussions and so make the conversations be less
> > confrontational.
> >
> > https://github.com/Danack/RfcCodex/blob/master/rfc_attitudes.md
> >
> > To be clear, this is only meant to help people understand other
> > people's view-points. It is not a fixed set of attitudes that I think
> > either are or should be followed.
> >
> > It's also not aimed at making everyone agree on all topics, but just
> > to help set people's expectations on how any particular RFC might be
> > received.
> >
> > cheers
> > Dan
> > Ack
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> I think this is a good idea. It appears to be a fair overview of various
> topics. Personally, instead of organizing it into the two main areas that
> you did, I think it would be better to maybe just list the various types of
> arguments used for/against RFCs, and what the pro/con positions are. As it
> is currently written, anything in the "less likely to pass" section might
> be taken as something that should be avoided - even in cases where such
> things do make sense. If, instead, we lay it out as "If you propose this,
> these are the arguments you're going to get as objections, and here are
> some of the justifications that have been used so far" someone might better
> be able to determine if their RFC for such a topic is justifiable, and if
> so, preempt some of the objections.
>
> --
> Chase Peeler
> chasepee...@gmail.com

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

Re: [PHP-DEV] [VOTE] Compact Object Property Assignment

[Jakob Givoni]

Hi Andrea,

On Wed, Apr 1, 2020 at 10:35 AM Andrea Faulds  wrote:
>
> Maybe it would be good to allow multiple-choice voting on why the RFC
> was not voted for, and also to provide an option in the syntax vote for
> not liking any of the syntax options, rather than just “Irrelevant”.

Right.
I considered multiple choice for the reason, but decided against it
since I was afraid it would lead to everybody just ticket most of the
reasons.
I think I can glean more info when you're limited to the most important one.

As for not liking any of the syntaxes - just don't vote on that poll then.
It seems to me it's pretty obvious it's not about the syntax anyway -
nothing would please the people who find COPA useless and any syntax
would be great for people who find it useful!
Anything in between just feels like discussing tabs vs spaces again
and again :-D I'm too old for that.

best,
Jakob

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

Re: [PHP-DEV] [VOTE] Compact Object Property Assignment

[Jakob Givoni]

On Tue, Mar 31, 2020 at 10:42 AM Larry Garfield  wrote:
>
> I really like that you're including a poll for the no-votes.  Thank you for 
> that.  However, as is they're all running together and making it hard to tell 
> where one ends and another begins.  Is there a way to separate out the tables 
> more?

I don't know. In which direction are they all running together for you?
Maybe you need to send a screenshot because I don't really see the problem...

Jakob

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

Re: [PHP-DEV] [VOTE] Compact Object Property Assignment

[Jakob Givoni]

Hi Sara!

On Tue, Mar 31, 2020 at 9:07 AM Sara Golemon  wrote:
>
> On the third vote (which syntax would be better), I didn't vote because my 
> answer is "None of the above". They're all kind of awful.  I'm not against 
> the concept of COPA, but every option on there makes me search for the "Nope" 
> button, and I lack the imagination to suggest anything better.

:-D
No worries. But for sure we won't get any further without imagination
at this point :-)

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

[PHP-DEV] [VOTE] Compact Object Property Assignment

[Jakob Givoni]

Heads up!

I've moved the RFC to the voting phase:

https://wiki.php.net/rfc/compact-object-property-assignment

Voting is open until the end of Monday, April 13 (your time zone :-).

Good night,
Jakob

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

Re: [PHP-DEV] [RFC] [VOTE] Compact Object Property Assignment

[Jakob Givoni]

On Tue, Mar 31, 2020 at 6:45 AM Lester Caine  wrote:
>
> The problem Jakob is that the new message is STILL attached to the
> original discussion. If you simply changed the 'DISCUSSION' to 'VOTE'
> then your email client still had the original message links in place.
> The whole email process is something of a mess, and the 'correct' way
> would have been to start with an empty message, add a clean subject and
> text and then send it to the list ...

ok, terribly sorry, will do that now then
thanks lester

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

Re: [PHP-DEV] [RFC] [VOTE] Compact Object Property Assignment

[Jakob Givoni]

On Mon, Mar 30, 2020 at 9:23 PM Jakob Givoni  wrote:
>
> Heads up!
>
> I've moved the RFC to the voting phase:
>
> https://wiki.php.net/rfc/compact-object-property-assignment
>
> Voting is open until the end of Monday, April 13 (your time zone :-).
>
> Good night,
> Jakob

Hi guys,

I don't understand why people are replying to this email that has
[VOTE] in the subject as if it's still the discussion thread.
Please let me know if there's something I can do about it.

Best,
Jakob

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

Re: [PHP-DEV] [RFC] [VOTE] Compact Object Property Assignment

[Jakob Givoni]

Hi Dan,

On Mon, Mar 30, 2020 at 9:50 PM Dan Ackroyd  wrote:
>
> Please don't forget to send a separate email announcing the voting
> with a separate subject.

This email already has a separate subject, right? Something else missing?

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

[PHP-DEV] [RFC] [VOTE] Compact Object Property Assignment

[Jakob Givoni]

Heads up!

I've moved the RFC to the voting phase:

https://wiki.php.net/rfc/compact-object-property-assignment

Voting is open until the end of Monday, April 13 (your time zone :-).

Good night,
Jakob

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

Hi Larry!

I have a lot of respect for the vision you're working on. Great
advances sometimes come out of great visions.
But let's not forget that so far it's only a vision and not all
visions come to fruition. We don't know - at the moment it's anybody's
guess.

At this point I hardly expect you to change your mind, and it's not
that you don't have all the right in the world to an opinion, but it
seems to me sometimes it's easy to confuse opinion with fact. Hence,
for the sake of my own sanity I will reply to some of your comments.
If you feel we're going around in circles, feel free to ignore my
replies. For sure, no need to double down on our disagreements.

On Sun, Mar 29, 2020 at 4:59 PM Larry Garfield  wrote:
>
> I went into this in my earlier Object Ergonomics post, but in short, it's 
> quite possible for a solution to be *too* narrow.
> It becomes useful in too small a subset of cases to justify its added 
> conceptual weight.

And what exactly is the added conceptual weight of COPA?
As I've stated time and time again, COPA doesn't introduce any new
concepts or complexities.
If you disagree with that, I'd really like to hear exactly what those
new concepts or complexities amount to in your eyes.

> (and contrary to the view of some, "if you don't like it don't use it" is 
> just not a thing when you're working in OSS,
> because someone is going to use it and you'll inherit that code).

Yeah, God forbid such madness! :-D

> A narrow solution can also inadvertently serve to make something too easy 
> that should be done rarely.
> [...]
> Or it would nudge users toward making more properties public so that they can 
> use the shorter COPA,
> but in the absence of a readonly keyword, asymmetric visibility, property 
> accessor, or something along those
> lines that is a net loss as it means more properties become public when they 
> really shouldn't be.

Hmmm, record-like data structures (structs?) - devils work in
disguise, for sure... :-D
If I were being arrogant I'd say that maybe allowing a trailing comma
in parameter lists will nudge users towards making methods take more
parameters than they should.
But I think it's prudent to be modest in such judgements.

> In this case, the problem with COPA as proposed is that it only works for 
> public properties that are assigned literally.  That is, in my experience, a 
> very rare case.

You see, here's the funny thing: It's rare because it's a hassle!
*MY* experience (I do have some 20 years' worth of such...) is that
people tend to use associative arrays instead for data records and the
like. COPA aims to change that.
And it's not true that the values have to be assigned literally - the
assignment can invoke a magic method which can validate and modify a
value and store it privately. I'm not saying that is good or bad, just
that it's possible and that fact should not be misrepresented.

> Most objects want and need to have private or protected properties for a 
> large variety of reasons, which would make COPA useless.

Ooops, careful with such an overstatement, buddy! I don't want to
enter into this debate here, just point out that this generalisation
is overreaching.
Again, some modesty would suit the debate better. Truth before emotions also.

> IMO, the combination of constructor promotion and named parameters would have 
> a much better ROI than a dedicated syntax,
> it would not suffer from the public properties problem, it would still allow 
> for constructor parameters that are not a 1:1 map to properties,
> but it would still serve to greatly reduce the amount of typing needed.  That 
> is, that approach offers more functionality for roughly the
> same or less additional syntax.

The proposed syntaxes for those features are much more complex than
COPA's - I hope I'm not misrepresenting it when I say that it
currently involves 2 new ways to write a constructor, moving
declaration of properties inside a method signature and a whole new
annotation/attribute paradigm to try to make sense of it all. And
we're nowhere near consensus on any of it.
The revived constructor promotion syntax cannot replace COPA without
named parameters - and named parameters has not made any significant
progress since 2013, unfortunately.
I would love to see some form of named parameters, but I'm not holding
my breath for it.

> In short, the cost-benefit calculation says this is useful in too narrow a 
> case, and has the potential to encourage bad design in the name of typing 
> less.
> Other alternatives address that problem space better.

To list the facts:
- Is COPA narrow? Yes
- Is COPA useless? No
- Will COPA encourage bad design and be overused? Opinion!
- Will COPA encourage struct-like objects over anonymous array? Yes
- Will COPA pollute the symbol/syntax space? Very little
- Does COPA have any implications for future language evolution? None
that have been shown so far
- Is COPA trivial to implement? Yes

Larry, keep up the great work with the Object 

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

Hi Levi,

On Sun, Mar 29, 2020 at 8:06 PM Levi Morrison
 wrHote:
>
> The current RFC text is not consistent with using `=` or `=>` for the
> assignments. The assignment `=` is vastly more common, though, and I
> don't understand why if we are using an array syntax we aren't using
> `=>`.

Not sure what you mean - are you saying the RFC has internal inconsistencies?

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

Re: [PHP-DEV] [RFC] Allow trailing comma in parameter lists

[Jakob Givoni]

Hi Rowan,

On Sat, Mar 28, 2020 at 4:01 PM Rowan Tommins  wrote:
>
> While I'd personally be fine with this change, I think we should
> understand why the previous proposal failed rather than just hoping the
> vote goes differently this time.

I think you have a good point here.
I've only been around for a short time so I can't comment on historical reasons.
And though I agree the proposal is logical and consistent, I have this
nagging feeling in the back of my brain:
Are we encouraging functions with long lists of parameters so that
they need to be on their own lines?
Personally I would probably never use this. But since the proposed
change sounds trivial, I have no strong feelings against it.

Best,
Jakob

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

Re: [PHP-DEV] Feature request - allow to append multiple elements to an array

[Jakob Givoni]

On Sun, Mar 29, 2020 at 4:08 AM Iván Arias  wrote:
>
> $arr[] = 1, 2, 3; // push these 3 values
> $arr[] = 1, 2, ... [3, 4, 5], 6; // push these 6 values

Just to play with this... - normally an assignment evaluates to the
value being assigned:

var_dump($arr[] = 1); // int(1)

What would this produce?

var_dump($arr[] = 1, 2, 3);

The first value, an array with 3 values or the full $arr?

Cheers,
Jakob

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

Hi Andrea,

On Sun, Mar 29, 2020 at 10:31 AM Andrea Faulds  wrote:
>
>
>  (function ($obj) {
>  $foo = "foo";
>  $bar = "bar";
>  $baz = "baz";
>
>  $vars = get_defined_vars();
>  foreach ($vars as $key => $value) {
>  $obj->$key = $value;
>  }
>  })($object);
>
> It's not very elegant though, and unfortunately you can't move the
> get_defined_vars() part to another function.


In an early version of my RFC I had included a long section of
examples of how you could do what COPA does but with current syntax,
each with its flaws.
I've tried everything from magic methods, anonymous classes and closures :-)
I removed it because it didn't seem to add much to the discussion and
the RFC became too long for a thorough read.

Thanks for the creativity though, I like playing with ideas like that,
but I must confess I frown upon functions like get_defined_vars() and
extract(), if you know what I mean :-D

I'd like to iterate that I believe the force of COPA is it's
simplicity - and I think it's gone unnoticed for many that the only
thing COPA adds to existing syntax is a set of square brackets around
the assignments. Everything else is familiar.

I repeat, the only difference between these two snippets is the [...]:

--
$myObj->a = 1;
$myObj->b = 2;
$myObj->c = 3;
--
$myObj->[
a = 1,
b = 2,
c = 3,
];


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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

Hi Rowan,

On Sun, Mar 29, 2020 at 10:00 AM Rowan Tommins 
wrote:

>
> myObj.with {
>  foo = 10
>  bar = foo + 20
> }
>

I really like the suggested "with" syntax, - in fact I had
contemplated something like that along the way.
The slight "problem", I think, is that, as you mention, adding a fully
fledged "with" syntax would imply that you could do a lot more than simply
assigning values to properties.
And while I agree that that would be cool, it feels like overkill for the
actual problem COPA is trying to solve.
Do you think a narrow version of "with" syntax could be incorporated into
COPA without causing frustration? Or would it be wise to give it its own
RFC?

I haven't researched if there have already been RFCs proposing something
along the lines of "with", and as such I have no idea if it has already
been discussed and found problematic.


> I'm not sure whether I like this idea or not, but I thought I'd share
> it, because I think COPA as currently proposed is too narrow a use case
> to deserve a special syntax.
>

I understand and fully agree that COPA is narrow, but I don't really
understand why that's a problem - I proposed it exactly because I felt that
its simplicity is its force.
Low hanging fruit is usually something I would encourage to go after.
I believe it's a trivial implementation that can help in uncountable
situations where you just need to assign values to a predefined data
structure in a single expression.

I'd really like to hear the arguments against such a cost-benefit
calculation.

Cheers,
Jakob

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

On Mon, Mar 16, 2020 at 6:48 AM Jakob Givoni  wrote:
>
> Hello Internals,
>
> I'm opening up my new RFC for discussion:
>
> https://wiki.php.net/rfc/compact-object-property-assignment
> - A pragmatic approach to object literals
>
> Let me know what you think!
>
> Best,
> Jakob

Hi again,

Since the two weeks mandatory discussion period is nearing its end and
there hasn't been any discussion activity for almost a week I'm
planning on opening the vote for COPA on Monday.

The RFC has been streamlined and updated to reflect all the discussion
points raised, - a couple of them are now in the Rejected Features
section and only the syntax question is still in the Open Issues
section. I haven't received any feedback on my proposed alternative
syntaxes so I guess we'll just put it to a vote (though I'm kind of
sad that nobody with solid internals experience has commented on the
implementability of any of them).

It's my first RFC, I know its a tough sell and I'm not expecting to be
successful the first time - I respect the vote 100%!

I really believe that COPA can help thousands of PHP developers
without introducing any new complexities to the language and my hope
is that perfect won't be the enemy of good this time around :-)

Any last words unsaid before the final lap commences?

Best regards,
Jakob

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

Re: [PHP-DEV] Re: [VOTE] Userspace operator overloading

[Jakob Givoni]

On Wed, Mar 25, 2020 at 6:28 AM Christoph M. Becker  wrote:
>
> It seems to me that the RFC is not sufficiently specific enough
> regarding the concatenation of instances of classes which implement
> __toString().

Exactly what I was thinking too. Would be nice with some examples on this.

> So if we ever wanted to change the value of
> PHP_OPERAND_TYPES_NOT_SUPPORTED, we'd introduce a BC break.  Therefore
> the constant's value likely will never change, so using NULL directly to
> signal unsupported operand types would be fine, wouldn't it?

Agree on this too.

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

Re: [PHP-DEV] Improving PHP's Object Egonomics: A broad analysis

[Jakob Givoni]

Hi Larry and Nicolas,

On Wed, Mar 25, 2020 at 9:24 AM Larry Garfield  wrote:

> > I'd like to propose something on the topic.
> > I'm adding object literals to the mix because that's another feature of the
> > language that we're missing a lot IMHO.
> > Actually, there is one existing syntax for objects: (object) [...]
>
> [...]
>
> 2) What's its order of execution with the constructor?  Vis, does the 
> constructor run after __create or before?  Does __construct get any 
> parameters passed to it?

That's the interesting question, though there's probably not any
sensible answer that works for all use cases. However, if this kind of
object casting (object literal notation) was limited to a certain
(extendable) internal class (SPL Struct?), we could have just a final
public function __construct(array $properties = []) that then
delegates the validation to an abstract __validation() method. Would
that at least be a useful alternative to constructor promotion?

> In that syntax, you have to remember which one comes first.  There's no 
> indication for the casual reader why
>
> public private $property;
>
> and
>
> private public $property;

I'm wondering - are there any use cases where you would have private
read and public write?

If not, maybe this issue can be simplified by adding (f.ex.)
"semiprivate" and "semiprotected" attribute keywords, the idea being
that they give readonly access to the anything else.

Though I think it would be great to have a nice, gracefully extensible
attribute syntax, maybe it's not necessary to fight over that for this
particular issue?

> Either way, what matters is who is in charge of dealing with the issues
> this might create. In both ways, what matters is that the original author
> won't be bothered for things that are not its responsibility. "I broke your
> app because you messed up with that private property on a class I
> authored?" no my problem. About final, I usually prefer using the "@final"
> annotation: it expressed exactly what I need to express as the author of
> the code: "if you extend, you're on your own - but I'm not dictating what
> you can/can't do either".
>
> I think this reasoning applies to my view on immutability :)

:-)
I can relate to that in general.
Though for immutability, I'm not so sure anymore...

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

I just realized that syntax C and D as proposed - without anything to
signify end of COPA - become really awkward when writing nested COPA:

$foo->
a = 1,
b = 2,
c = (new Foo)->
a = 3,
b = 4,.
,
;

How do we indicate that the nested block ends and jump back to the outer one?

On Sat, Mar 21, 2020 at 9:47 PM Jakob Givoni  wrote:
>
> Hi Andrea, thanks for your feedback.
> Let's talk about syntax then :-)
>
> The currently suggested syntax is
>
>  -> [
>  = ,
> ...
> ]
>
> The  can be an existing object:
>
> $foo->[a = 1];
>
> Or a new, yet anonymous, object:
>
> (new Foo)->[a = 1];
>
> 1. The (normal) brackets
> ===
>
> The reason I think it's necessary to wrap the new Foo in brackets is
> because it's a language construct and not an expression in itself.
> Wrapping it in brackets make it an expression.
>
> For example, these are both syntax errors (missing brackets):
> new Foo->a = 1;
> new Foo()->setA(1);
>
> In this RFC I did not want to propose changing the lexer/parser to
> make that possible, since my focus was to suggest a rather trivial
> implementation. I'm open to change this view, but only if someone with
> solid knowledge of internals come forward and promise that it's a good
> idea.
>
> 2. The arrow
> ==
>
> When the arrow follows an object expression it suggest we're doing
> something on that object, like accessing a property (set/get) or
> calling a method.
> There are exceptions though: When the object expression is followed by
> curly or square brackets it means we're accessing it as if it were an
> array:
>
> $foo[1]
> $foo{1} // Deprecated
>
> And when it's followed by normal brackets, we're invoking it as a callable:
>
> $foo()
>
> I see a window of opportunity here though: Since the curly brackets
> were deprecated in PHP 7.4 we could repurpose it for COPA:
>
> $foo{a = 1, b = 2}
>
> Is it too soon?
>
> 3. The square brackets
> ==
>
> The assignments need to be grouped together, somehow (at least I think
> that's the sane thing to do?) - we cannot use curly brackets as, like
> you say, that's reserved to create an expression that evaluates to a
> property name:
>
> $foo->{a =1, b = 2}; // syntax error, unexpected '='
>
> That leaves us with either normal brackets or square brackets:
>
> $foo->(a = 1, b = 2);
> $foo->[a = 1, b = 2];
>
> Which one is more natural when we're dealing with structure data?
>
> 4. The property name
> 
>
> All I can say is that I really don't want to add anything that is not
> strictly necessary, like the arrow before each property, unless it's
> adding something of actual value.
> Familiarity you say... yes, I can see that, but it gets very verbose
> with that leading arrow... In my opinion array literal syntax is
> already too verbose for me.
>
> 5. The equals sign
> ==
>
> I don't really know why => was chosen for array assignment, since we
> use simple = to assign values everywhere else. Since i prefer it less
> verbose, and since we already
> use = in $foo->a = 1 I think a single = is the best option.
>
> COPA is NOT object initializer
> ===
>
> COPA can follow any object expression and has nothing to do with
> object construction in itself. You can use COPA as many times as you
> like at any point in an object's life.
> Though object initializer would also solve what COPA is solving, COPA
> doesn't introduce any new concepts, just new syntax.
> I don't know why object initializer and other similar proposals failed
> in the past, but I wanted to try something different, less elaborate
> and more pragmatic.
> I don't know if COPA has any better chance than those that came before :-)
>
> I am going to suggest a few alternative syntaxes that we can also vote
> on, but only after they've been vetted by experienced internals
> developers.
>
> Syntax A - the initial one
>
> Syntax B:
> $foo{
>   a = 1,
>   b = 2,
> };
>
> Syntax C:
> $foo->a = 1,
>   b = 2;
>
> Syntax D:
> $foo->a = 1,
>->b = 2;
>
> Syntax E:
> $foo->(
>   a = 1,
>   b = 2,
> );
>
> We can try to iterate over these as well, please let me know what you think!
>
> On Sat, Mar 21, 2020 at 1:31 PM Andrea Faulds  wrote:
> >
> > Hi,
> >
> > Jakob Givoni wrote:
> > > Hello Internals,
> > >
> > > I'm opening up my new RFC for discussion:
> > >
> > > https://wiki.php.net/rfc/compact-object-property-assignment
> > > - A pragmatic approach to 

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

Hi Andrea, thanks for your feedback.
Let's talk about syntax then :-)

The currently suggested syntax is

 -> [
 = ,
...
]

The  can be an existing object:

$foo->[a = 1];

Or a new, yet anonymous, object:

(new Foo)->[a = 1];

1. The (normal) brackets
===

The reason I think it's necessary to wrap the new Foo in brackets is
because it's a language construct and not an expression in itself.
Wrapping it in brackets make it an expression.

For example, these are both syntax errors (missing brackets):
new Foo->a = 1;
new Foo()->setA(1);

In this RFC I did not want to propose changing the lexer/parser to
make that possible, since my focus was to suggest a rather trivial
implementation. I'm open to change this view, but only if someone with
solid knowledge of internals come forward and promise that it's a good
idea.

2. The arrow
==

When the arrow follows an object expression it suggest we're doing
something on that object, like accessing a property (set/get) or
calling a method.
There are exceptions though: When the object expression is followed by
curly or square brackets it means we're accessing it as if it were an
array:

$foo[1]
$foo{1} // Deprecated

And when it's followed by normal brackets, we're invoking it as a callable:

$foo()

I see a window of opportunity here though: Since the curly brackets
were deprecated in PHP 7.4 we could repurpose it for COPA:

$foo{a = 1, b = 2}

Is it too soon?

3. The square brackets
==

The assignments need to be grouped together, somehow (at least I think
that's the sane thing to do?) - we cannot use curly brackets as, like
you say, that's reserved to create an expression that evaluates to a
property name:

$foo->{a =1, b = 2}; // syntax error, unexpected '='

That leaves us with either normal brackets or square brackets:

$foo->(a = 1, b = 2);
$foo->[a = 1, b = 2];

Which one is more natural when we're dealing with structure data?

4. The property name


All I can say is that I really don't want to add anything that is not
strictly necessary, like the arrow before each property, unless it's
adding something of actual value.
Familiarity you say... yes, I can see that, but it gets very verbose
with that leading arrow... In my opinion array literal syntax is
already too verbose for me.

5. The equals sign
==

I don't really know why => was chosen for array assignment, since we
use simple = to assign values everywhere else. Since i prefer it less
verbose, and since we already
use = in $foo->a = 1 I think a single = is the best option.

COPA is NOT object initializer
===

COPA can follow any object expression and has nothing to do with
object construction in itself. You can use COPA as many times as you
like at any point in an object's life.
Though object initializer would also solve what COPA is solving, COPA
doesn't introduce any new concepts, just new syntax.
I don't know why object initializer and other similar proposals failed
in the past, but I wanted to try something different, less elaborate
and more pragmatic.
I don't know if COPA has any better chance than those that came before :-)

I am going to suggest a few alternative syntaxes that we can also vote
on, but only after they've been vetted by experienced internals
developers.

Syntax A - the initial one

Syntax B:
$foo{
  a = 1,
  b = 2,
};

Syntax C:
$foo->a = 1,
  b = 2;

Syntax D:
$foo->a = 1,
   ->b = 2;

Syntax E:
$foo->(
  a = 1,
  b = 2,
);

We can try to iterate over these as well, please let me know what you think!

On Sat, Mar 21, 2020 at 1:31 PM Andrea Faulds  wrote:
>
> Hi,
>
> Jakob Givoni wrote:
> > Hello Internals,
> >
> > I'm opening up my new RFC for discussion:
> >
> > https://wiki.php.net/rfc/compact-object-property-assignment
> > - A pragmatic approach to object literals
> >
> > Let me know what you think!
> >
> > Best,
> > Jakob
> >
>
> I really don't like this `(new Foo)->[]` syntax for a few reasons:
>
> * It doesn't seem unreasonable to me to imagine that `->` could be
>overloaded to take a value that isn't a string for the property name.
>Of course, that would be `(new Foo)->{[]}` not `(new Foo)->[]`, but it
>is too close for comfort for me.
> * It looks like short array syntax, but it's not an array, in fact
>it is an object, which is a similar but different thing.
> * Brackets normally enclose an expression: if I have `new Foo`, I can
>enclose that as `(new Foo)`, yet this is adding something extra to the
>`new` expression while not being part of it? This is surprising to me.
>If it affects the `new`, it should be inside the brackets.
> * Do we need the brackets?
>
> I think there are some alternative syntaxes that could be used as
> inspiration.
>
> C99 has a v

Re: [PHP-DEV] [RFC] is_literal()

[Jakob Givoni]

On Sat, Mar 21, 2020 at 4:58 PM Craig Francis  wrote:

> I'm happy to use a different name; but I should add that is_numeric() isn't 
> really a type, there are other functions such as is_writable(), and the taint 
> extension uses is_tainted().

Right, good points. However, to my logic, whether or not the value was
created from a literal is not something you can infer from the value
itself, it needs an accompanying flag or something.

I'll suggest is_from_literal() as a more precise formulation.

> I've talked to Paul Dragoonis and Derick Rethans recently (they both kindly 
> did talks at PHP-SW); when I mentioned it to Paul, I was told that's where I 
> should start looking, and that was the correct terminology; and Derick helped 
> confirm some of these ideas (but we were walking to the pub at the time).

Sounds like you were having fun though :-)

> And while I keep trying, I don't know enough about C, or the internals of PHP.

Appreciate the effort.

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

Re: [PHP-DEV] [RFC] is_literal()

[Jakob Givoni]

On Sat, Mar 21, 2020 at 3:26 PM Craig Francis  wrote:
>
> As to the name, it's to work alongside functions such as
> is_int(), is_string(), etc - is that a good enough reason?

I think it could cause confusion since int and string are value types,
- literal is not a type as such, it merely describes the way the value
was created.

> I'm under the impression that PHP already defines these as literals

Does anyone know if that is correct? Does PHP remember how the string
variable / constant was created?

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

On Wed, Mar 18, 2020 at 12:27 AM Michał Brzuchalski
 wrote:

> Using Object Initializer enforce that if a class is instantiated with the 
> Object Initializer,
> at the end of the instantiation and properties initialization, all visible 
> properties
> (depends on initialization scope) are initialized, otherwise, a 
> RuntimeException is thrown.
> This helps to avoid bugs where a property is added to the class but forgot to 
> be assigned
> it a value in all cases where the class is instantiated and initialized. 
> https://wiki.php.net/rfc/object-initializer#restrictions

Got it.
Out of curiosity, would you be able to summarize why you believe your
proposal was not accepted?

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

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

[Jakob Givoni]

On Wed, Mar 18, 2020 at 7:15 PM Mark Randall  wrote:
> Well, they shouldn't be casting a vote in the first place.
Hear! Hear!

Ok, I don't mean to be harsh, but rather to demonstrate a way that you can
express agreement with something someone else has said without repeating
it.
Maybe if more voters participated in discussions in this simple way, asking for
voting reasons post hoc would not come up time and time again...

Or to vary it:
- Ditto
- I agree
- True
- What (s)he said

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

On Mon, Mar 16, 2020 at 9:07 PM Jakob Givoni  wrote:
> Thank you for your feedback so far!
I've rewritten parts of the RFC substantially
(https://wiki.php.net/rfc/compact-object-property-assignment)
so take another look if you too have ever wanted to
create, populate and send an object inside a function call.

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

On Tue, Mar 17, 2020 at 9:31 AM Rowan Tommins  wrote:
> Hm, I see, that does reduce the boilerplate somewhat, although it's still
> split across two classes, and probably therefore two files, which is not
> great.
As an alternative to passive associative arrays, it's a small price to pay for
splitting concerns and having a documented signature for the data structure.
Named parameters is another alternative (unfortunately outside reach for now)
that would work great for a limited number of arguments. COPA does not
make named parameters obsolete, but works great for any number of arguments.

> You're missing some code in your example, though, because you've documented
> one of the options as optional, implying the others should be mandatory; in
> which case you need something like this in the constructor:
I've rewritten parts of the RFC and some examples substantially,
and added your view of mandatory arguments in the "Open Issues" section.

> It might be interesting to have the syntax run before the constructor
> rather than after, or trigger some other magic method which could do
> tidying and validation, so it could apply to more circumstances.
Hmmm, in the Write Once Properties RFC they seem to believe
that object construction is a "fuzzy" term and that lazy initialization
is a feature.

We can add better 'automagic' support for mandatory arguments,
filtering and validation
in incremental proposals, to avoid biting off more than we can chew, but we
have to start somewhere.

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

On Tue, Mar 17, 2020 at 4:33 PM Matthew Brown  wrote:
> I don't think it's conflicting _if you insist on brackets_ after the new 
> expression. PHP Parser grammar for "new" expressions is
>
> T_NEW class_name_reference ctor_arguments
>
> If you allowed the shorter syntax, ctor_arguments would allow an 
> object_properties entry.
Sounds good, but this is unfamiliar territory to me, so would you mind
giving an example of an
alternative syntax you think would work?

> I'm sure Nikita could clarify, though.
I know Nikita is busy but I hope he'll stop by this RFC one of these
days, as I have a few
things that needs his expertise :-)

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

Thank you, Michał, for chiming in :-)

On Tue, Mar 17, 2020 at 10:52 AM Michał Brzuchalski
 wrote:
> For object initializer, I was hoping to introduce a feature which with the 
> benefits of typed properties
> could reduce the boilerplate on initializing object and setting their 
> properties in one expression.
Exactly my motivation with COPA as well;
- Typed properties - check,
- Reduce boilerplate - check,
- Initializing and setting properties in one expression - check.

> With object initializer, this could be reduced to:
>
> $this->dispatch(new SomeCommand { foo = 'bar', baz = false });
And with COPA it would be;
$this->dispatch((new SomeCommand)->[ foo = 'bar', baz = false ]);
Subtle differences, when compared to the currently available alternative.

> But as mentioned IMO this is a different feature than what you propose and 
> personally I see no point
> in reducing only assignment statements without combining it with object 
> construction for these kinds
> of small objects, DTO's, commands, queries and events.
Maybe you missed that COPA can be combined with object construction?

> but personally I don't need a constructor at all in those cases since we
> have typed properties and it looks like they could be also marked as 
> read-only in next major PHP version.
Exactly, and as I couldn't help notice that you voted for the Write
Once Properties RFC, which clearly states that
object construction is a fuzzy term (meaning don't take it too
seriously) and lazy initialization is a feature...

I hope you will either reconsider your support for COPA or let me know
what I'm missing so I can
consider other directions.

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

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

[Jakob Givoni]

On Mon, Mar 16, 2020 at 8:20 PM Dan Ackroyd  wrote:
> * Explaining exactly why you're voting no can be hard as there can be
> multiple overlapping reasons for voting no.
>
> * It sets up arguments about what is and isn't a valid reason for voting no.
>
> * It drives people who might want to vote no away from the project, if
> they have to take the extra time to justify their position.
Maybe a list of standard answers to choose from could be a good
compromise:
- Don't like the syntax
- Don't find the feature useful
- Limits future changes
- There are better solutions
- Is complicated to implement
- Breaks backwards compatibility
- Prefer not to say

All are valid reasons for voting no.
If there are multiple applicable reasons, just pick one.
Or allow picking multiple?
If having to pick one of these is enough to drive people away,
maybe it's for the best... ;-D

> For some RFCs, there just isn't a good path forward for them.
Even so, giving a reason for voting no will make that much clearer,
and maybe stop more RFCs in their tracks.

> btw I think there's a bigger problem on some RFCs being accepted,
> particularly where people who aren't core maintainers are voting on
> things that really need an informed understanding of internals.
True, - but likewise, there are purist who don't use PHP in the real world
and reject something pragmatic because it's not fancy enough.
It's important to be humble in a democracy.

Best regards,
Jakob

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

On Mon, Mar 16, 2020 at 6:48 AM Jakob Givoni  wrote:
> Let me know what you think!

Thank you for your feedback so far!

I'd be really curios to know what authors of the referenced RFCs think
about this, f.ex.
Michał (brzuc...@php.net), Andrey (andrewg...@rambler.ru) and Nikita
(ni...@php.net)

Is simple inline object population useful in itself?
Is the proposed implementation as trivial as I think it is?

Best regards,
Jakob

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

On Mon, Mar 16, 2020 at 8:29 PM Marco Pivetta  wrote:
> That kinda makes the entire feature quite useless/uninteresting to me: if a 
> this does is desugaring into a set of assignments, then I'm not sure what its 
> advantage is.
I'm sorry about that, but the motivation of the RFC is quite clear in
the "Motivation" section.
If those goals are not interesting to you then COPA won't help you.

> I was kinda hoping for an atomic state mutation across multiple fields, heh...
Sounds like another RFC (that may make it in PHP 9.x+ ;-D)

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

On Mon, Mar 16, 2020 at 10:40 AM Rowan Tommins  wrote:
> Thanks for having another go at this feature, which I think a lot of people
> would like in some form.
I agree!

> Maybe we want to have all four, but that would leave us with a lot of
> different ways of initialising objects, which might not be such a good
> thing.
Remember that the RFC explicitly says it's not an object initializer,
nor does it solve "named parameters" which you mention.
If I had the choice, I'd go with named parameters when creating an
object, but I don't and
this is the next best thing. It's simple and it doesn't introduce any
new concepts.
It just allows you to do something inline that you could until now
only do line by line.

> You mention using "argument bag" objects in place of named parameters, but
> that feels like it would be even more awkward than using an associative
> array.
The associative array is a common pattern, but it defeats name and
type checking.
An Options class add almost no extra boilerplate since you simply move
the properties from
the main class to the Options class.
Notice that in contrary to your example, I simply copy the Options
object whole into the main class.

> COPA can only validate individual
> parameters, not the whole object; so it's hard to complain if the user
> forgets a mandatory field
Correct, the goals for COPA are quite clear in the "Motivation"
section and that kind of validation
is not one of them
Luckily you can still do things the way you prefer without COPA if it
doesn't suit you :-)

Best,
Jakob

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

On Mon, Mar 16, 2020 at 9:31 AM Marco Pivetta  wrote:
> What happens if you have an expression that throws?
>
> class Foo
> {
> public $a;
> public $b;
> public $c;
> }
>
> $instance = new Foo();
>
> function iThrow() {
> throw new \Exception();
> }
>
> try {
> $foo ->[
> a = 'a',
> b = iThrow(),
> c = 'c',
> ];
> } catch (\Throwable $e) {
> var_export($foo); // ???
> }

Hi Marco!
Trivial question - let's see what happens:

Just replace COPA with the old syntax and run it:

try {
$foo->a = 'a';
$foo->b = iThrow();
$foo->x = 'c';
} catch (\Throwable $e) {
var_export($foo); // ???
}

Result:
Foo::__set_state(array(
   'a' => 'a',
   'b' => NULL,
   'c' => NULL,
))

So the first property will be set, the rest will be left as they were.

Best,
Jakob

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

On Mon, Mar 16, 2020 at 9:26 AM Christian Schneider
 wrote:
> [] suggests an array but then is uses literals and = instead of 
> 'strings'/$vars and => which looks wrong to my PHP eye.
That's ok, square brackets are usually related to arrays and what I
want is something similar to array literals.
The rest of the syntax is exactly the same as when you assign
properties on a object currently.

> you want to initialise so many properties manually instead of through some 
> sort of constructor.
Yes, exactly. From the RFC:
"The purpose of this feature is to lighten the effort of populating
data structures, especially medium to large ones."

And as I say, since we don't have named parameters, this is a
pragmatic alternative.

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

On Mon, Mar 16, 2020 at 9:10 AM Matthew Brown  wrote:
> I love the idea!
Thanks Matthew!

> The syntax for new objects looks a little verbose – would it be possible to 
> use
>
> $foo = new Foo()[
>   property1 = "hello",
>   property2 = 5,
> ];
The short answer: I don't think so.

This is not possible (though it's arguably 'nicer'):

new Foo()->doSomething(); // syntax error, unexpected '->'

Not sure why, but it's necessary to wrap the instantiation in brackets:

(new Foo())->doSomething(); // Ok

If someone can explain why, it would be enlightening!

Furthermore, dropping the arrow would create conflicting syntax with
array access:

$foo[1]; // Array access, give me the element with index 1, can be
used on objects as well
$foo[a = 1]; // Property assignment... ???

I'll update the RFC to reflect your proposal.

Thank you,
Jakob

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

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

[Jakob Givoni]

On Mon, Mar 16, 2020 at 1:29 PM Mike Schinkel  wrote:
> If we had that we could list the reasons and the number of votes that choose 
> those reasons on the RFC for historical purposes.

Thanks Mike, exactly what I was thinking when I started writing RFC:
COPA (https://wiki.php.net/rfc/compact-object-property-assignment)!

As you can see in my "Voting" section, I had the idea to capture
reasons for no-votes, to document it in the outcome of the RFC, should
it fail.
It would have saved my research quite a bit if I had had the no-vote
reasons for the RFCs I reference at the bottom.

+1 on the idea from me!

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

[PHP-DEV] [RFC] [DISCUSSION] Compact Object Property Assignment

[Jakob Givoni]

Hello Internals,

I'm opening up my new RFC for discussion:

https://wiki.php.net/rfc/compact-object-property-assignment
- A pragmatic approach to object literals

Let me know what you think!

Best,
Jakob

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties

[Jakob Givoni]

On Mon, Mar 16, 2020 at 4:47 AM Rowan Tommins  wrote:
> I'm sure different people will react differently, but my intuition is quite
> the opposite: I would probably call the inline assignment to the property
> an "initial value", not a "default value", and I would intuitively compare
> it to assigning it in the constructor. I would also understand the intent
> of "write once" to be "once initialized, can't be overwritten", so would
> personally have no expectation that I could initialize a variable in both
> the property definition and the constructor.

Interesting, so if I understand you correctly, you think of a property with an
initial/default value to be *initialized* before the constructor, but
a property without it is
*initialized* in the constructor or later (at first assignment of value)?

Is this concept of initialized/non-initialized properties something that is
more or less well-described in the language? If so, I'd like to read it.
Seems like a fuzzy concept to me so far, unfortunately...

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties

[Jakob Givoni]

On Sun, Mar 15, 2020, at 8:48 AM, Marco Pivetta wrote:
> I think what will happen is that people will start requesting for read-only
> properties with default values to be over-writable-once

Exactly, I think that intuitively, developers will not see a default
value as an actual "write".
They will expect to be able to overwrite it once.

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

Re: [PHP-DEV] Idea for RFC: Compact Object Property Assignment

[Jakob Givoni]

Hi again,

As mentioned, I'm working on the RFC "Compact Object Property Assignment",
and I'd like to request some RFC karma for my wiki account in order to
create the page:

Username: jgivoni
Email: ja...@givoni.dk

Thanks,
Jakob

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

Fwd: [PHP-DEV] Idea for RFC: Compact Object Property Assignment

[Jakob Givoni]

Hello Internals,

I'm working on an RFC with the subtitle
> A pragmatic approach to the "impossible" object literals and named parameters

I'll be proposing a syntax to assign values to multiple properties on
the same object in a single block - i.e. inline.
It's motivated by many of the same headaches that lead to various
proposals for object literals, object initializers and named
parameters, none of which were successful so far.

I call it COPA - Compact Object Property Assignment, and it is exactly
that and nothing else.

Though not limited to such, it will make working with things like DTOs
and argument bags significantly nicer.

In contrast to previous RFCs, I believe the strength of this one is
simplicity on all levels.

Any advice before I move forward with publishing the actual RFC?

Best regards,
Jakob Givoni

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