Re: [PHP-DEV] Experimental features

[MKS Archive]

> On Oct 10, 2022, at 8:04 PM, David Gebler  wrote:
> 
> This is what's bothering me. Either these "experimental" features have
> passed RFC and will be part of the language, as you've said above, or
> they're actually experimental i.e. not finalized and implementing behaviour
> and syntax which may be subject to change or even dropped entirely
> depending on the feedback cycle. 

If they are not experimental and their usage is finalized, then they are 
in-fact approved and they would be absolutely no different from the existing 
RFCs today.

You cannot have experimental features unless those features have the potential 
to not be included in the future language and/or those features have the 
potential to be improved before they are finalized. Otherwise, what's the point?

BTW, I googled several different phrases trying to find a horror story in 
Node.js because of their experimental features, but the only thing I was able 
to find was people glowing about the features that are currently experimental 
and/or the excitement when a feature graduated to fully supported, for example:

https://nodesource.com/blog/experimental-features-in-node.js/

Maybe you can find examples of downsides of having experimental features in 
Node.js (or some other language/platform) that I was unable to find? If so, it 
would be instructive to learn from their experiences.

> Using the trivial json_validate() example (although as others have said, a
> simple new function is probably a bad example), 

(As an aside, I disagree that a new function would be a bad example. I think it 
would be a good use-case for experimental features because of how decoupled it 
would be from the rest of the language, and it would help to see if a lot of 
people use the function before committing to including it.)

> If it's the former, the library can just check if PHP >= 8.3 and fall back
> to userland implementation / polyfill for earlier versions. This is just
> what we have now, where approved new features are part of a versioned
> release.

Not all potentially useful functions can reasonably be implemented in userland 
PHP.

> If it's the latter, everyone touching the experimental version, directly or
> indirectly, may have to rip out and change code later which renders the
> work they've put in to use the experimental feature in their code pointless.

That is not a hard software engineering problem. Software developers have been 
isolating 3rd party dependencies for decades. There's no reason why developer 
could not isolate (most) potential experimental features in the same way.

> I'm inclined to suggest if you opt in to an experimental language feature,
> you are by definition making at least an implicit declaration that you know
> what you're doing,

You speak of people "knowing what they are doing" as if it were a binary thing, 
i.e. they know what they are doing or they do not. Let me use an analogy for 
you here to try to make the counter point.

There are a handful of doctors of the world's leading heart surgeons.  They 
absolutely "know what they are doing."  But if I have brain cancer and need a 
tumor excised, I would not let any one of those doctors touch me unless they 
were also celebrated as a brain surgeon. I am guessing you would feel the same.

Similarly, someone can be an excellent software developer but not have strong 
DevOps or sysadmin skills. In my 10+ years working with PHP I met, knew, and 
worked with *many* people like that. And for many years, *I* was one of those 
people.

> so the idea people using these features wouldn't have
> the skills to spin up a container or install something on a VM doesn't
> convince me, personally.

Not every developer is a polymath. Some are excellent at writing software but 
cannot configure a server or a VM or Docker container to save their life.  In 
my LinkedIn I could probably give you a list of 100 developers what that would 
apply to.  

IOW, they are a lot of excellent heart surgeons out there but they just don't 
know how to fix a brain.

-Mike

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

Re: [PHP-DEV] Specify abstract parent methods for traits

[MKS Archive]

> On Sep 18, 2022, at 7:51 AM, Mohammad Amin Chitgarha  
> wrote:
> 
> Hi.
> 
> Currently, it's possible that, inside a trait's function, use the parent 
> method of a class using the trait. This way, not only it's implicitly 
> supposed the trait is used in a class having a parent, but also the parent 
> class has such a method. It doesn't seem to be a good practice, as stated in 
> the answers of this question 
> (https://softwareengineering.stackexchange.com/questions/371067/should-a-trait-refer-to-parent-methods).
> Also, it's almost impossible to override a parent method (using the same 
> signature) using a trait. This is useful if you have to inherit multiple 
> classes from a base class, but also override one (or more) of the base 
> methods with a common functionality provided by a trait.
> There are some workarounds to these problems (specially talking about the 
> later one), but they have their own disadvantages:
> Define a trait function with the same signature but a different name and use 
> it. The main disadvantage is that it's a different method, and is not 
> polymorphic.
> Do (1), include the trait in the derived class(es), then override the parent 
> method in all derived classes and manually call the trait function. Not 
> perfect because you have to copy the same code for all derived classes.
> 
> Stick with parent:: in the trait function. Implicit and not good (e.g. static 
> analyzers and IDEs cannot help).
> 
> Change the parent class to use traits. This is not always possible, as it 
> might be someone else's code.

How often have you (or anyone else?) found a need to inherit someone else's 
class and then need to override one of their methods via a trait? A need that 
you felt you could not easily work around in some other reasonable way?

If yes, could you please give some examples?

-Mike

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

Re: [PHP-DEV] [RFC] Asymmetric visibility

[MKS Archive]

Hi Ollie,

> On Aug 8, 2022, at 6:12 AM, Ollie Read  wrote:
> 
> On Mon, Aug 8, 2022, at 3:54 AM, Mike Schinkel wrote:
>> 3.) I have concerns about the proposed methods isProtectedSet() and 
>> isPrivateSet().  
>> 
>> These names feels like we are asking if some thing "Set" is "Protected" or 
>> "Private" where no such "thing" exists in this context.  
>> 
>> In other words it reads as if you are asking "Is it a *protected* Set?" or 
>> "Is it a *private* Set?"  Such naming also does not relate to the Property 
>> itself which is what the prefix verb "is" is acting on.
>> 
>> I would propose instead we consider the following are these instead would be 
>> asking the *ability* to "Set" the Property is "Protected" or "Private" where 
>> The Property is again what the prefix verb "is" is acting on:
>> 
>> isSetProtected()
>> isSetPrivate()
>> isGetProtected(), and
>> isGetPrivate()
> 
> I feel almost as if we shouldn't pollute ReflectionProperty with these 
> additional methods but should instead have something like 
> ReflectionAsymmetricProperty, which would in turn extend ReflectionProperty. 

On my 3rd point that you quoted my primary concern was that I felt the RFC 
solution of "isSet()" was hard to reason about but my own suggestion 
almost incidental. I felt if I voiced my concerns then it would be incumbent 
upon me to at least suggest an alternative.

OTOH, I'm not sure I would embrace yet another reflection class. I think that 
would make an already (IMO) too-complex reflection class hierarchy even more 
complex.

Maybe a better solution could be to add an optional $flags parameter to the 
existing is() methods, something like?

isPublic(ReflectionProperty::GETTABLE)
isProtected(ReflectionProperty::GETTABLE)
isPrivate(ReflectionProperty::GETTABLE)

isPublic(ReflectionProperty::SETTABLE)
isProtected(ReflectionProperty::SETTABLE)
isPrivate(ReflectionProperty::SETTABLE)

isPublic(ReflectionProperty::GETTABLE & ReflectionProperty::SETTABLE)
isProtected(ReflectionProperty::GETTABLE & ReflectionProperty::SETTABLE)
isPrivate(ReflectionProperty::GETTABLE & ReflectionProperty::SETTABLE)

#fwiw

-Mike

> I guess it depends on how it's handled. If all property handling is updated 
> so that "public int $number" is identical to "public:get public:set int 
> $number", there's no issue, but if we treat those with separate visibilities 
> to be additional, it probably makes sense to be somewhat separate.
> 
> While isGetProtected() is technically false for "public int $number", if it's 
> not inferred, it's semantically incorrect. A good example of this is 
> ReflectionMethod::getPrototype, which throws an exception if there's no 
> prototype. Although this is somewhat bizarre, it is at least a thing we do.
> 
> ---
> Best Regards,
> *Ollie Read*

Re: [PHP-DEV] [RFC] [VOTE] Constants in traits

[MKS Archive]

> On Jul 8, 2022, at 12:29 PM, Jordan LeDoux  wrote:
> 
> On Tue, Jul 5, 2022 at 2:39 PM shinji igarashi  > wrote:
> 
>> Hello internals,
>> 
>> I've started the vote for the Constants in Traits RFC:
>> https://wiki.php.net/rfc/constants_in_traits
>> 
>> The vote will end on 19. July 2022.
>> 
>> Thanks!
>> 
>> --
>> Shinji Igarashi
>> 
>> 
> I don't have a vote, but I wanted to address this concern about the
> "usefulness" of traits, since the *voting* stage is rather the wrong place
> to bring up the idea that the existence of the feature itself is a
> negative.
> 
> In my view, the "correct" way to use traits is for them to be entirely
> self-contained. That is, if you can put the trait in *any* class, and have
> that trait work as intended *even if* it makes no semantic sense to do so,
> then it's a good trait. This is currently somewhat difficult to do in
> certain situations. Some of the things the trait may need must live outside
> the trait, such as constants. This fact promotes further problematic usage
> of the feature.
> 
> Requiring something like class constants to be external to the trait
> *forces* the kind of trait designs that they have complained about. Voting
> "no" because you want to see the feature removed instead is
> counter-productive to the process of improving the language itself if the
> RFC in question helps correct an oversight of the original feature design
> as stated by the original implementer of this feature and helps to promote
> more non-problematic usage of the feature.

+1 

> 
> I don't know how else to view that position except for wanting to keep
> design flaws in a feature so that you have additional arguments in the
> future to remove it.
> 

That seems to be a very plausible analysis...


-Mike

Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3

[MKS Archive]

> On Jun 11, 2022, at 10:01 PM, Larry Garfield  wrote:
> 
> On Sat, Jun 11, 2022, at 4:14 PM, Rowan Tommins wrote:
>> On 09/06/2022 17:34, Larry Garfield wrote:
>>> Last year, Nuno Maduro and I put together an RFC for combining the 
>>> multi-line capabilities of long-closures with the auto-capture compactness 
>>> of short-closures ... Arnaud Le Blanc has now picked up the flag with an 
>>> improved implementation ... The RFC has therefore been overhauled 
>>> accordingly and is now ready for consideration.
>>> 
>>> https://wiki.php.net/rfc/auto-capture-closure
>> 
>> 
>> First of all, thanks to all three of you for the work on this. Although 
>> I'm not quite convinced yet, I know a lot of people have expressed 
>> desire for this feature over the years.
> 
>> To go back to the point about variable scope: right now, if you're in a 
>> function, all variables are scoped to that function. With a tiny handful 
>> of exceptions (e.g. superglobals), access to variables from any other 
>> scope is always explicit - via parameters, "global", "use", "$this", and 
>> so on. If we think that should change, we should make that decision 
>> explicitly, not treat it as a side-effect of syntax.
>> 
>> I don't find the comparison to a foreach loop very convincing. Loops are 
>> still only accessing variables while the function is running, not saving 
>> them to be used at some indeterminate later time. And users don't "learn 
>> to recognize" that a loop doesn't hide all variables from the parent 
>> scope; it would be very peculiar if it did.
> 
> There are languages that do, however.  Some languages have block-scoped 
> variables by default (such as Rust), or partially blocked scoped depending on 
> details.  PHP is not one of them, but to someone coming from a language that 
> does, PHP's way of doing things is just as weird and requires learning.  


Working in Go now for several years I'd say one of its biggest foot guns that I 
consistently run into when doing code reviews and even in my own code is 
block-level scoping where one variable shadows the same named variable outside 
the block and the inner variable is updated when the intention was to update 
the outer variable.

In short, block level scoping is a convenience that does more harm than good. 
At least in my experience.

Thus I would highly recommend *not* adding block level variable scope to PHP 
where a block in the middle of a function shadows a variable outside the block, 
and that variable is used below the block, such as for a return value.  

#jmtcw #fwiw

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

Re: [PHP-DEV] The future of objects and operators

[MKS Archive]

> On May 6, 2022, at 6:16 PM, Jordan LeDoux  wrote:
> 
> Hello all,
> 
> I took a while away after my operator overload RFC was declined. I've been
> mulling for the last few months how to move forward while respecting the
> concerns and feedback of those who abstained and those who voted against.
> But I feel like a separate discussion needs to happen first after
> considering many different approaches.
> 
> # There is Considerable Demand For Improved Control of Operators with
> Objects
> 
> This doesn't apply to all operators. I have not seen any comments in the
> last few months of digging of people who are desperate for the pow operator
> ( ** ) for instance. However, many people who work with math in PHP have
> use for at least the arithmetic operators and I see this comment frequently.
> 
> Totally separate from the math domain, I've seen many comments about the
> desire to control the comparison operators: >, >=, ==, <=, <, !=, <>. This
> is something that would have numerous applications outside of mathematics,
> and there's even been an RFC worked on (that was declined in 2018) by Rudi
> to implement just comparisons.
> 
> # Different Voters Have Different Concerns
> 
> This is an issue that almost all RFC authors must deal with of course, but
> this particular subject suffers from it more severely than most. For
> instance, in some of the past proposals that were more limited than mine,
> there were comments that a full operator overloading solution should be
> provided instead of something halfway.
> 
> However one of the comments I received more than once was that I should
> separate out the comparison operators into its own RFC, since those have
> applications outside the math domain.
> 
> # Is Math A Valid Use Case?
> 
> One of the more shocking (to me personally) pieces of feedback that I
> received from more than one person is that math is not a valid use case in
> PHP. I am... unsure about what to think of this opinion. I guess I would
> like to discuss and find out if this is widely believed among voters.

I will repeat what I suggested back before the RFC was voted on, and that is 
you consider *starting* your campaign for operator overloads with an RFC to add 
a built-in Math class (or set of classes) to PHP, one(s) that can have all the 
operator overloading it/they need(s).

Minimally the design process in the open would be insightful for everyone 
interested in the topic even if the RFC did not get accepted — although the 
intent should be that it would — because it would change the operator overload 
discussion from a very abstract one to a very concrete one. 

It could also illustrate the benefit for operator overloading, and illustrate 
the design process of deciding on how operators are overloaded and what the 
benefits and tradeoffs are of different choices.

If the RFC did not pass, at least it could result in an understanding of which 
operators minimally need to be overloaded for the Math use-case and serve as a 
blueprint for adding Math objects in userland if and when sufficient 
general-purpose operator overloading could get added to PHP.

Further, if an RFC to add a built-in Math object to PHP passed it would 
effectively eliminate the red-herring of "I don't do heavy math work."  Such an 
RFC would also, of course, not have the other two (2) categories of objections 
that you named in your other email.

Again, #jmtcw

-Mike

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

Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation

[MKS Archive]

> On Mar 26, 2022, at 6:15 PM, Rowan Tommins  wrote:
> 
> On 25/03/2022 14:38, Arnaud Le Blanc wrote:
>> I find that sprintf() is easier to read in most cases. One reason for this is
>> that the text is separated from the code.
> 
> 
> Funnily enough, I find sprintf() *harder* to read for the same reason - 
> particularly once there are more than two or three parameters, and more than 
> a bit of punctuation between them.
> 
> A large part of that is because the placeholders are positional rather than 
> named, so you have to keep track of which is which; but by the time you've 
> got named placeholders, you might as well have variable interpolation.
> 
> As a silly example, I prefer this:
> 
> $sentence = "The {$adjectives[0]} {$adjectives[1]} {$nouns[0]} jumped over 
> the {$adjectives[2]} {$nouns[1]}";
> 
> To this:
> 
> $sentence = sprintf(
>'The %s %s %s jumped over the %s %s',
>$adjectives[0],
>$adjectives[1],
>$nouns[0],
>$adjectives[2],
>$nouns[1]
> );
> 
> I think that's partly a matter of taste, though, because I've definitely seen 
> people happily using both styles. And there are certainly situations (like 
> translation strings) where placeholders of some sort work better than 
> straight interpolation.

Choice of sprintf() vs string interpolation *can* be more than a matter of 
taste, and this from someone who once greater preferred the latter.

There are (at least) two use-cases I am familiar with where using printf() and 
sprintf() with placeholders have benefits over string interpolation.

1.) Internationalization of human-readable strings can be more easily 
facilitated when the literal text is kept distinct from the interpolated values.

2.) Reduced memory allocation and string manipulation when strings are used for 
logging that may be discarded when logging levels are set to less than "log 
everything." 

#fwiw

> That's why I thought it was interesting to see what other languages have 
> done. While PHP and Ruby have obvious links back to Perl, many languages 
> which didn't start off with string interpolation have added it in later 
> versions, e.g. C#, Scala, JavaScript, Python. Clearly there were sufficient 
> voices in favour in each of those communities to add it; and in each case, 
> they added *expression* interpolation, not just the *variable* interpolation 
> supported by Perl and PHP.
> 
> I won't be too upset if this feature doesn't get added, but I do think it 
> would be a nice addition.
> 
> Regards,
> 
> -- 
> Rowan Tommins
> [IMSoP]
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

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