Re: [PHP-DEV] [VOTE] Interface Default Methods

[Brent Roose via internals]

I want to pitch in, agreeing with Larry's message here. 

- There are multiple real life use cases where the combo trait/interface could 
be replaced by interface default methods
- Several modern language apply the technique in one form or another, so it's 
already proven to be valuable
- There are a multitude of userland devs who'd benefit from this feature
- The only argument I've heard against this RFC is "it goes against my 
definition of what an interface should be". I was also thought that same 
definition, and I also had to unlearn it. Just like I had to unlearn the "only 
one return per method rule" we were taught in college

Brent

> On 12 Jul 2023, at 20:17, Larry Garfield  wrote:
> 
> On Wed, Jul 12, 2023, at 4:00 AM, G. P. B. wrote:
>> On Mon, 3 Jul 2023 at 01:11, Levi Morrison  wrote:
>> 
>>> Chatter on the [Interface Default Methods RFC][1] has been quiet for
>>> the past 6 days, and the feature freeze deadline is fast approaching
>>> for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks
>>> as usual.
>>> 
>>> Thanks to everyone who discussed weaknesses in the RFC during the
>>> discussion phase.
>>> 
>>>  [1]: https://wiki.php.net/rfc/interface-default-methods
>>> 
>> 
>> Although I like the idea, I think the main reason for the pushback is how
>> close this is being voted on before feature freeze when the RFC +
>> implementation was updated very recently before.
>> And personally I think, considering this, I would also delay implementing
>> this.
>> We have at least 2 other major RFCs that are being pushed back (Property
>> Hooks and Function autoloading) due to time constraints.
>> 
>> Maybe it's time for a more meta discussion about the absurdly long release
>> process PHP has of releasing many intermediate versions that seem to get no
>> testing from userland.
>> 
>> For everyone against this feature, I would urge you to understand the
>> distinction between "type classes" and Java-like "interfaces" (which is
>> effectively what PHP interfaces are).
>> A good article is the following one:
>> https://diogocastro.com/blog/2018/06/17/typeclasses-in-perspective/
>> 
>> I also find it baffling the lack of understanding around this feature.
>> Generic programming exists, and it operates on a level where a method can
>> have a "concrete" default representation and still represent the genericity
>> to its fullest.
>> Examples have already been given, such as the Comparable, Equatable, or
>> Iterator type classes.
>> Considering, Haskell, Rust, Scala, and modern PL theory sees no issue with
>> that, I struggle to understand the resistance here.
> 
> If I could play armchair shrink for a moment, I suspect a lot of people come 
> from a background where "interface is just the behavior definition, not 
> implementation" was drilled into them.  Which... is the case in older Java 
> when most of us went through school using older Java.  So it's natural to 
> think that is just a rule of how languages work, and so default methods in 
> interfaces is just some weird nonsense from people who don't understand 
> language theory because you didn't learn it in school.
> 
> At least, I know that description applies to me, so I'm assuming it applies 
> to at least some other folks around here. :-)
> 
> Realizing "oh, wait, I was wrong about the theory of how things work" is 
> uncomfortable, and hard for a lot of people.  I was initially luke-warm on it 
> for that reason. But seeing how many languages have adopted some form of 
> default methods and lived to tell the tale is convincing for me that it 
> actually is a viable "build up a class from separate pieces without having to 
> manually write 50 proxy methods" solution.  There may be smaller issues with 
> it that need to be ironed out (enforcing methods being defined, it working 
> better with interface properties, etc.), but the core idea seems to be sound.
> 
> It's taken me a while to get used to going through that "oh wait, I was 
> wrong" process, so at this point it's not an ego-hit.  But that's not a 
> process everyone has gone through.
> 
> In short, I suspect at least much of the pushback is "that is weird and not 
> normal, according to the normal I first learned, so it must be a bad idea," 
> and people just stop there.
> 
> (If you voted no and the above description doesn't apply to you, please do 
> explain what your alternate reasoning is, because RFC authors desperately 
> need more feedback than we get right now.)
> 
> --Larry Garfield
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Nullable intersection types

[Brent Roose]

Hi internals

I wanted to apologise for the poor wording I used in my previous mail when I 
said "oversight". What I meant to say is what Nicolas described in his followup 
mail: feature freeze as a time to polish implementations. I personally consider 
nullability to be more of an implementation polishment, but I realise the 
syntax question makes it a more difficult question.

While my personal experience with 7.0 and the lack of nullability was really 
annoying, I'm sure we'll all survive if 8.1 doesn't include nullability 
support. 

I just wanted to clarify those points, sorry if my previous mail caused any 
inconvenience. 

Kind regards
Brent

> On 28 Jul 2021, at 09:29, Nicolas Grekas  wrote:
> 
> as proposed by Nikita and Joe, I'm submitting this late RFC for your
>> consideration for inclusion in PHP 8.1. Intersection types as currently
>> accepted are not nullable. This RFC proposes to make them so.
>> 
>> I wrote everything down about the reasons why here:
>> https://wiki.php.net/rfc/nullable_intersection_types
>> 
>> Please have a look and let me know what you think.
>> 
> 
> Hi everyone,
> 
> Thank you for the contributions made to the discussion so far. I'm mostly
> AFK these days, hiking in Greece. That gives me time to think about
> comments made here, among other things :)
> 
> Given the strong opposition from some, I considered withdrawing the RFC.
> But since I also see some nice support, I decided not to: even if the
> proposal is rejected, everyone should have the right to express their
> opinion, and the vote is the only option to not let only the most vocal or
> the most eloquent decide for the others.
> 
> For the same reason, I'm not going to restrict the voting options to
> (X)|null as some requested. I will change my mind if we spot that some
> syntax would put us in a corner. But so far and while I tried to be as
> careful as possible, all syntax proposals are future-proof to me. I get
> that some have strong coding style preferences, but that doesn't make a
> technical argument. It's true that deciding to allow no brackets won't
> allow us to force them later on. By why would we *force* them in the first
> place? While you may not like relying on it, operator precedence is a nice
> thing. I would hate having to put brackets around every single expression
> in PHP. For types, there are only two to three operators: we don't have to
> remember the full precedence table. And only one precedence makes sense
> anyway, so it's easy to remember. I'm not advocating that we should forbid
> brackets. Actually I'm going to vote for allowing both with and without
> them, because I don't want to force my preferred coding style to others.
> 
> I do have a preference for using the `?` operator. It is compact and
> nullability *is* a flag. I'm reviewing code that use foo|null|bar, other
> that use foo|bar|null. That makes reading the code harder. About its
> precedence, I explained why I didn't need to be creative in the RFC: `?`
> has to be the lowest precedence type-operator. Any other options would make
> no sense from a logical pov. It would be so sweet and consistent to be able
> to use it all the time to express the nullability flag. I would mind if we
> allowed both `?` and `|null` btw.
> 
> Intersection types are a really useful addition to the language, please
> don't suggest I framed it otherwise. I just thought that they would be a
> lot less useful if they were not nullable, especially considering that they
> could be part of public signatures that have to be maintained with BC in
> mind. I'm happy that some agree with this and share their experience about
> it.
> 
> Nullability is a special beast in PHP. We have a range of operators
> dedicated to it. That's also why I think it deserves special care, and why
> I think it's important to have this discussion before 8.1 is out. To me,
> the feature freeze is also useful for this: polishing features that are
> about to be released. I don't see us rushing here.
> 
> Let's do a careful and rational analysis of the proposal and vote on the
> very asked question. We do have enough time.
> 
> TL;DR: I'm carefully looking for blockers and I'm calling for more examples
> if you spotted one!
> 
> Cheers,
> Nicolas
> 
>> 

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

Re: [PHP-DEV] [RFC] Nullable intersection types

[Brent Roose]

Hi all

From a userland developer point of view:

- PHP 7.0 types were a pain because of non-nullable types, the feature only 
became really useful as of PHP 7.1
- I share many people's opinion that this falls in the category of oversight
- I think (A)|null is the only sensible way to go

Sidenote: weren't there any prior cases where an RFC was accepted only to have 
found out an oversight which resulted in that RFC to be postponed to the next 
release?

Kind regards
Brent

> On 26 Jul 2021, at 16:14, Sara Golemon  wrote:
> 
> On Fri, Jul 23, 2021 at 4:58 AM Nicolas Grekas 
> wrote:
> 
>> https://wiki.php.net/rfc/nullable_intersection_types
>> 
>> 
> I've commented on the PR and in R11 a bit already, but I'd like to state my
> position here for the record.  I do see the value in having nullability,
> but I can't disagree enough with the `?X` syntax no matter how
> technically right the argument about operator precedence is.  Even ignoring
> that literally nobody carries around a complete operator precedence table
> in their head, we simply can't predict how making this decision now will
> impact future plans for combined intersection/union types.  The same
> argument honestly goes for every other syntax proposed, including
> `(X)|null` which is also prone to making things worse.
> 
> Nullable intersection types *IS* an implementation of combined
> intersection/union types, even if a narrow one. Those have not been planned
> out or approved, and they're too broad to sneak in post feature freeze.
> Period. Let's take the coming months to flesh out the edge cases on
> combined types.  Let's maybe even look into type aliasing, which may have
> the side effect of making combined types more readable (or maybe less, who
> knows!).
> 
> Most importantly, let's accept the fact that PHP's release cycle is only 12
> months and we had pandemics that lasted longer than that.  Next year is
> right around the corner.
> 
> TL;DR - I've decided my vote.
> 
> -Sara

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

Re: [PHP-DEV] Readonly properties and interfaces

[Brent Roose]

> On 7 Jul 2021, at 23:16, Larry Garfield  wrote:
> 
> On Wed, Jul 7, 2021, at 7:32 AM, Brent Roose wrote:
>> Hi internals
>> 
>> With the readonly properties RFC almost certainly accepted, I'd like to 
>> discuss an idea that's slightly related to them.
>> 
>> One of the problems that readonly properties solve is that they reduce 
>> the overhead of writing getters and setters. This is especially 
>> noticeable in objects that hold lots of data — data transfer objects, 
>> value objects, entities. And while public readonly properties will be a 
>> style of programming that not everyone likes, it's clear from the vote 
>> on the readonly RFC, as well as the community feedback, that it's a 
>> feature wanted by many.
>> 
>> That brings me to interfaces: currently we're only allowed to define 
>> methods on interfaces; historically this makes sense, since interfaces 
>> are meant to define behaviour, and not the implementation. Most OO 
>> language define behaviour using methods, and state using properties, 
>> which in turn are used to define the implementation.
>> 
>> But now, readonly properties are added.
>> 
>> Suddenly, class properties aren't just used for state anymore, they are 
>> also used to expose that state in an immutable way to the outside, 
>> where we'd use public getters (behaviour) and private properties 
>> (state) in the past, we can now combine them as public readonly 
>> properties. Wouldn't that imply that there are at least some cases 
>> where interface properties could also make sense?
>> 
>> A simple example:
>> 
>> Imagine we've got 10 different classes that share some behaviour: they 
>> are identifiable by a UUID. Next, imagine we've got a function that can 
>> specifically work with all classes that have a UUID. Proper OO teaches 
>> us to write an interface for this behaviour `Identifiable` or `HasUuid` 
>> or something alike. This interface would probably require its 
>> implementers to expose a `getUuid(): string` method. 
>> 
>> Without interfaces being able to define properties, we'll now have to 
>> implement a `getUuid()` method on all our 10 classes, nullifying the 
>> advantage we got from using `public readonly string $uuid` in the first 
>> place. If, on the other hand, this functionality was supported, we 
>> could write our interface like so, and wouldn't have to worry about any 
>> more boilerplate code:
>> 
>> ```
>> interface HasUuid
>> {
>>public readonly string $uuid;
>> }
>> ```
>> 
>> With the addition of readonly properties, now seems like a good time to 
>> discuss changing these rules. I realise these questions touch the core 
>> ideas of OO, so I reckon some people might have another opinion and I'd 
>> like to hear your thoughts.
>> 
>> To give you some more reading material, there is a precedent for 
>> interface properties in other languages:
>> 
>> - TypeScript supports them [1]
>> - C# supports them, albeit using property accessors [2]
>> - Swift supports them via Protocols [3]
>> 
>> Looking forward to hearing your thoughts.
>> 
>> Kind regards
>> Brent
>> 
>> [1] 
>> https://www.typescriptlang.org/docs/handbook/type-compatibility.html 
>> <https://www.typescriptlang.org/docs/handbook/type-compatibility.html 
>> <https://www.typescriptlang.org/docs/handbook/type-compatibility.html>> 
>> [2] 
>> https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/interface-properties
>>  
>> <https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/interface-properties>
>>  
>> <https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/interface-properties
>>  
>> <https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/interface-properties>>
>>  
>> [3] https://docs.swift.org/swift-book/LanguageGuide/Protocols.html 
>> <https://docs.swift.org/swift-book/LanguageGuide/Protocols.html> 
>> <https://docs.swift.org/swift-book/LanguageGuide/Protocols.html 
>> <https://docs.swift.org/swift-book/LanguageGuide/Protocols.html>> 
> 
> The property accessor RFC (which didn't get to a vote) discussed this, and 
> specifically proposed making properties part of the interface for... 
> basically all the reasons given here.
> 

I thought the RFC didn't go to vote because Nikita didn't feel like it 
warranted the complexity:

> This RFC overlaps with the Property Accessors RFC. 

[PHP-DEV] Readonly properties and interfaces

[Brent Roose]

Hi internals

With the readonly properties RFC almost certainly accepted, I'd like to discuss 
an idea that's slightly related to them.

One of the problems that readonly properties solve is that they reduce the 
overhead of writing getters and setters. This is especially noticeable in 
objects that hold lots of data — data transfer objects, value objects, 
entities. And while public readonly properties will be a style of programming 
that not everyone likes, it's clear from the vote on the readonly RFC, as well 
as the community feedback, that it's a feature wanted by many.

That brings me to interfaces: currently we're only allowed to define methods on 
interfaces; historically this makes sense, since interfaces are meant to define 
behaviour, and not the implementation. Most OO language define behaviour using 
methods, and state using properties, which in turn are used to define the 
implementation.

But now, readonly properties are added.

Suddenly, class properties aren't just used for state anymore, they are also 
used to expose that state in an immutable way to the outside, where we'd use 
public getters (behaviour) and private properties (state) in the past, we can 
now combine them as public readonly properties. Wouldn't that imply that there 
are at least some cases where interface properties could also make sense?

A simple example:

Imagine we've got 10 different classes that share some behaviour: they are 
identifiable by a UUID. Next, imagine we've got a function that can 
specifically work with all classes that have a UUID. Proper OO teaches us to 
write an interface for this behaviour `Identifiable` or `HasUuid` or something 
alike. This interface would probably require its implementers to expose a 
`getUuid(): string` method. 

Without interfaces being able to define properties, we'll now have to implement 
a `getUuid()` method on all our 10 classes, nullifying the advantage we got 
from using `public readonly string $uuid` in the first place. If, on the other 
hand, this functionality was supported, we could write our interface like so, 
and wouldn't have to worry about any more boilerplate code:

```
interface HasUuid
{
public readonly string $uuid;
}
```

With the addition of readonly properties, now seems like a good time to discuss 
changing these rules. I realise these questions touch the core ideas of OO, so 
I reckon some people might have another opinion and I'd like to hear your 
thoughts.

To give you some more reading material, there is a precedent for interface 
properties in other languages:

- TypeScript supports them [1]
- C# supports them, albeit using property accessors [2]
- Swift supports them via Protocols [3]

Looking forward to hearing your thoughts.

Kind regards
Brent

[1] https://www.typescriptlang.org/docs/handbook/type-compatibility.html 
 
[2] 
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/interface-properties
 

 
[3] https://docs.swift.org/swift-book/LanguageGuide/Protocols.html 
 

Re: [PHP-DEV] [RFC] noreturn type

[Brent Roose]

Hi Peter and internals

> On 11 Mar 2021, at 07:51, Peter Stalman  wrote:
> 
> On Wed., Mar. 10, 2021, 11:22 Matthew Brown, 
> wrote:
> 
>> If a significant number agree I can add a secondary vote on noreturn vs
>> never, but never introduces more of a BC risk.
>> 
> 
> Hi Matt,
> 
> I like this RFC, but I'd like to see the RFC cover if any other languages
> have a similar return type.

What made it clear to me was this:

returning nothing (void) isn't the same as not returning (noreturn, eg throw or 
exit).

Having read that somewhere on Twitter made it easier for me to reason about. 
It's a useful feature in the static analysis world.

> 
> The definition of `void` is that it has no return value, so I too agree
> that the keyword `noreturn` is too close in meaning to `void`.
> 
> I'd also like to throw the word `deadend` or something similar into the
> ring, to make things a bit clearer.
> 
> Thanks,
> Peter

Kind regards
Brent

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

[PHP-DEV] Changes to finfo and imap functions

[Brent Roose]

Hi internals

The chagelog for PHP 8.1 lists the two following changes: 


- Fileinfo:
  . The fileinfo functions now accept and return, respectively, finfo objects
instead of resources.

- IMAP:
  . The IMAP functions now accept and return, respectively, IMAPConnection 
objects
instead of resources.

I suppose these changes are part of the move away from "resources everywhere" ? 
I was wondering whether these function will still accept resource objects in 
PHP 8, or if support for them is completely removed. 

I tried searching externals.io  for a previous discussion 
but could only find https://externals.io/message/111297#111298 
 

Kind regards
Brent

Re: [PHP-DEV] Inheritance Cache

[Brent Roose]

Hey Dmitry

Out of curiousity: how does this compare to preloading? From what I understand 
preloading also links classes, which was one of the most important differences 
between preloading files and simply storing them in opcache. Does this change 
mean that preloading becomes much less relevant since class linking can now 
also happen at runtime?

Kind regards
Brent

> On 5 Feb 2021, at 15:03, Dmitry Stogov  wrote:
> 
> Hi,
> 
> I'm glad to present the result of my recent work - Inheritance Cache.
> 
> https://github.com/php/php-src/pull/6627
> 
> This is a new transparent technology that eliminates overhead of PHP class
> inheritance.
> 
> PHP  classes are compiled and cached (by opcahce) separately, however their
> "linking" was done at run-time - on each request. The process of "linking"
> may involve a number of compatibility checks and borrowing
> methods/properties/constants form parent and traits. This takes significant
> time, but the result is the same on each request.
> 
> Inheritance Cache performs "linking" for unique set of all the depending
> classes (parent, interfaces, traits, property types, method types involved
> into compatibility checks) once and stores result in opcache shared memory.
> As a part of the this patch, I removed limitations for immutable classes
> (unresolved constants, typed properties and covariant type checks). So now
> all classes stored in opcache are "immutable". They may be lazily loaded
> into process memory, if necessary, but this usually occurs just once (on
> first linking).
> 
> The patch shows 8% improvement on Symphony "Hello World" app.
> 
> I'm going to merge this patch into master on next week.
> Please review and give your comments.
> 
> Thanks. Dmitry.

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

Re: [PHP-DEV] [DISCUSSION] ReflectionType::accepts

[Brent Roose]

Hi Nikita

I was indeed thinking about the former: acceptsValue; but I would excpect that 
if the concrete value is a subtype of the current type, the fuction would also 
return true. What I'm basically interested in: will this method throw a type 
error when I pass this value? In other words: "will this method accept this 
value?"

Is that in line with your view on `acceptsValue`? 

Kind regards
Brent

> On 29 Jan 2021, at 10:33, Nikita Popov  wrote:
> 
> On Fri, Jan 29, 2021 at 9:15 AM Brent Roose  <mailto:bre...@stitcher.io>> wrote:
> Hi Internals
> 
> Since the addition of union types, it has become a little more cumbersome to 
> determine whether a given parameter type accepts specific input. Personally 
> I've been reusing this code blob in several places because of it:
> 
> ```
> /** @var \ReflectionNamedType[] $types */
> $types = match ($type::class) {
> ReflectionUnionType::class => $type->getTypes(),
> ReflectionNamedType::class => [$type],
> };
> 
> foreach ($types as $type) {
> if (! is_subclass_of($type->getName(), ShouldBeStored::class)) {
> continue;
> }
> 
> // …
> }
> ```
> 
> I wonder whether we would discuss adding a method on ReflectionType that 
> accepts any given input, and tells you whether that input is valid for that 
> type or not. I was thinking about `ReflectionType::accepts(string|object 
> $input): bool` but we could discuss another name. With it, the above example 
> could be refactored like so:
> 
> ```
> if (! $type->accepts(ShouldBeStored::class)) {
> return;
> }
> 
> // …
> ```
> 
> I believe this method should accept both class names and objects to be 
> consistent with the existing reflection API. It would also work with 
> intersection types, if they are to be added some day.
> 
> What do you think?
> 
> Kind regards
> Brent
> 
> There's two possible notions of what "accepts" does:
> 
> * acceptsValue(), whether a given value satisfies the type. Probably needs a 
> flag to determine whether strict_types semantics should be used or not.
> 
> * isSubTypeOf(), whether a given type satisfies the type in a subtyping 
> relationship.
> 
> You seem to be mixing these two up into one concept, even though they are 
> quite different. Which is the one you actually need? (I am much more open to 
> providing the former than the latter.)
> 
> Nikita

[PHP-DEV] [DISCUSSION] ReflectionType::accepts

[Brent Roose]

Hi Internals

Since the addition of union types, it has become a little more cumbersome to 
determine whether a given parameter type accepts specific input. Personally 
I've been reusing this code blob in several places because of it:

```
/** @var \ReflectionNamedType[] $types */
$types = match ($type::class) {
ReflectionUnionType::class => $type->getTypes(),
ReflectionNamedType::class => [$type],
};

foreach ($types as $type) {
if (! is_subclass_of($type->getName(), ShouldBeStored::class)) {
continue;
}

// …
}
```

I wonder whether we would discuss adding a method on ReflectionType that 
accepts any given input, and tells you whether that input is valid for that 
type or not. I was thinking about `ReflectionType::accepts(string|object 
$input): bool` but we could discuss another name. With it, the above example 
could be refactored like so:

```
if (! $type->accepts(ShouldBeStored::class)) {
return;
}

// …
```

I believe this method should accept both class names and objects to be 
consistent with the existing reflection API. It would also work with 
intersection types, if they are to be added some day.

What do you think?

Kind regards
Brent

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

Re: [PHP-DEV] #[Deprecated] Attribute

[Brent Roose]

Hi Sara

> On 22 Dec 2020, at 19:54, Sara Golemon  wrote:
> 
> On Tue, Dec 22, 2020 at 12:35 PM Nicolas Grekas <
> nicolas.grekas+...@gmail.com> wrote:
> 
>> It would be great to allow adding this attribute on classes. What about
>> allowing it right now and not bind it to any runtime side-effect? That
>> would allow static analyzers to do their job. Same for consts and
>> properties by the way.
>> 
>> Also, it would be very useful to add named parameters to the attribute,
>> namely: "package" (the name of the package that declares the deprecation)
>> and "version" (the version of that package that introduced the
>> deprecation), next to the message.
>> 
>> This is critical info when building reports of deprecations.
>> 
>> 
> You could do that now with a polyfill from userspace.  If the annotation
> need not have an effect, then it's just any other userspace implementation.

The difference is that PHP core has the ability to force standarization. 
There's already JetBrains' implementation of #[Deprecated], which Psalm and 
PhpStan also support, but it's not a real standard. Maybe the FIG would one day 
step in to decide these kinds of things, but the reality is that many major 
frameworks don't follow FIG as closely as they used to. I think there's value 
in adding attributes in the core, with the goal only being static analysis. 
It'll allow for consistency and that's a valuable thing.

> 
> -Sara


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

Re: [PHP-DEV] [RFC] Enumerations

[Brent Roose]

Hi Larry and Ilja

It's great to see you're looking into enums, thanks! I have a few 
considerations from a userland point of view. I've been maintaining a userland 
enum implementation for a while now [1] so I think I share a thing or two about 
my experience.

- Scalar enums are spot on, exactly what I'd expect.
- Support with match is awesome, and I think makes it so that array key support 
isn't necessary.
- Others already addressed that serialization and deserialization would be a 
nice feature. A common use case is to store enums in a datastore of some kind, 
and it would be nice not having to make dedicated factories for them.
- The `case` syntax feels quirky. I assume it's because PHP wouldn't allow 
something like this:

```
enum Suit: string {
  Hearts = 'H';
  Diamonds = 'D';
  Clubs = 'C';
  Spades = 'S';
}
```

Finally, I've got one (rather large) concern about object enums, specifically 
with methods implemented on a per-enum basis. I did the same [2] when I first 
implemented my userland package. From my research back then, I believe only 
Java [3] allowed this behaviour. If you've checked out that link, you've seen 
that value specific methods have been removed in v2. That's with good reason: 
they turned out to rather cumbersome to maintain and even a bit useless. Here's 
why:

- You example shows one method, the `color` one, which is still kind of 
manageable. If you allow enum methods though, you'll often end up with more 
than one method: `label`, `color`, `index`, `name`, `id`, are a few that come 
to mind. In the end an enum grows very large and unmanageable, with often lots 
of repeated code.
- Enum value methods actually are the state pattern [4] in disguise. One 
difference being that enums objects can't manage their own internal state, so 
they become less useful in applying the state pattern compared to using classes.

I think enums shouldn't aim to solve the state pattern. It's out of scope for 
what enums should do and their way of solving the state pattern will be worse 
in practice compared to using classes. I'd say it would be good to keep the 
defintion of enums in mind:

> "an enumerated type […] is a data type consisting of a set of named values 
> called elements, members, enumeral, or enumerators of the type. The 
> enumerator names are usually identifiers that behave as constants in the 
> language." [5]

"Named values" and "constants" being the keywords here, there's no "behaviour" 
implemented by enum values, which is why only a small amount of languages allow 
this kind of functionality.

I realise enum objects might seem like a good idea to provide more 
value-specific functionality in a concise way, but let's compare per-value 
methods with a method on the base enum:

```
enum Suit implements Colorful {
  case Hearts {
public function color(): string {
  return "Red";
}
  }
 
  case Diamonds {
public function color(): string {
  return "Red";
}
  }
 
  case Clubs {
public function color(): string {
  return "Black";
}
  }
 
  case Spades {
public function color(): string {
  return "Black";
}
  }
 
  public function shape(): string {
return "Rectangle";
  }
}
```

vs

```
enum Suit implements Colorful {
case Hearts;
case Diamonds;
case Clubs;
case Spades;

public function color(): string {
return match ($this) {
Suit::Hearts, Suite::Diamonds => "Red",
Suit::Clubs, Suite::Spades => "Black",
}
}
}
```

In summary:

- If you'd use enum objects for "simple functionality", I'd say `match` will 
always be the more concise way.
- If you'd use enum objects for handling complex state, you're better off using 
classes and properly implementing the state pattern.

I don't think enum objects should be a blocker, if people _really_ want it then 
fine. Based on my experience though, I'm rather sure that they won't be very 
useful, and would love to hear your opinion on the matter.

Kind regards
Brent

[1] https://github.com/spatie/enum
[2] https://github.com/spatie/enum/tree/v1#enum-specific-methods
[3] https://www.geeksforgeeks.org/enum-in-java/
[4] https://en.wikipedia.org/wiki/State_pattern
[5] https://en.wikipedia.org/wiki/Enumerated_type

> On 7 Dec 2020, at 10:30, Rowan Tommins  wrote:
> 
> On 07/12/2020 01:00, Paul Crovella wrote:
>> Instance state being global is a well-known problem with singletons.
>> Maybe don't use singletons then. Or simply document them as was done
>> in the RFC. I'd prefer the former since singletons don't seem to buy
>> much here but problems, though maybe I'm missing something.
> 
> 
> Yes, I think you are missing something - or maybe I am, because I honestly 
> can't picture what it would look like for enums *not* to be singletons.
> 
> Would Suit::Hearts be a constructor, producing a new instance each time, each 
> with its own state? Would we then overload ===, so that Suit::Hearts === 
> Suit::Hearts was still true somehow?
> 

Re: [PHP-DEV] PHP 8 release announcement page on php.net

[Brent Roose]

Hi internals

Regarding the matter of a sandbox, one of my colleagues open sourced a Laravel 
sandbox that runs straight in the browser and uses docker containers, with a 
little work you can extract away the Laravel part and have it run plain PHP. 
Here's the source: https://github.com/spatie/tinker.app 
 and here's it running: 
https://tinker.app/ 

On topic now, regarding the promo page: this kind of marketing is where PHP 
lacks a little bit, so I think it's a great initiative. A simple one pager just 
to promote PHP, one you can share with both PHP and non-PHP developers, and 
teases the right amount to get some people interested. A perfect page to share 
on hackernews, reddit, twitter and the likes. I think it's a great first step!

Kind regards
Brent

> On 14 Oct 2020, at 13:18, Dik Takken  wrote:
> 
> On 14-10-2020 03:41, Larry Garfield wrote:
>> This sounds like a fantastic idea.  The inline-run capability of Go and 
>> Rust's documentation is a huge win.  Writing good sample code for the 
>> documentation would be an interesting challenge, but it's the sort of thing 
>> that can be done over time.
> 
> I second this. However, then we should also make sure that the example
> code actually works, and on which PHP versions. As soon as examples can
> be run right from the documentation pages, the examples will be run far
> more frequently than they are now, simply because it is so much easier
> to do. Broken examples will cause more disappointing experiences.
> 
> I don't know if example code is currently tested automatically. If not,
> adding a sandbox for running them may also offer an opportunity for
> automatic testing.
> 
> Besides experimenting with example code, a sandbox may also be used to
> expose runtime information. Think of generated opcodes, the JIT compiled
> assembly, the AST.
> 
> At some point I can imagine adding a documentation page about
> performance, optimization and JIT. That page could enable users to see
> how an example code snippet is compiled, optimized and how type
> inference is done. Change the code, change opcache settings and see what
> happens. It is interesting to toy around with and it helps to get more
> exposure to some impressive developments of recent years.
> 
>> The interesting question would be how to configure it to ensure it doesn't 
>> become a security issue.  We'd probably need to lock down the environment's 
>> ini settings *hard* to make sure it can't do any outgoing communication at 
>> all.
> 
> Trying to lock things down will also limit the example code that can be
> run. And we run the risk of overlooking things. Maybe we could learn
> from other languages, how they set up their sandbox environments.
> 
>> If we need hosting for that, I work for a hosting company and we're happy to 
>> help.
> 
> I think we all highly appreciate that offer.
> 
> Regards,
> Dik Takken
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Re: [PHP-DEV] RFC: Support for multi-line arrow functions

[Brent Roose]

Hi internals

The reason multi-line short closures are so valued by userland devs is because 
they are shorter to write and prettier to read. While some of us might not 
agree on the definition of "prettier to read", it was one of the key arguments 
for adding short closures in the first place:

> Anonymous functions in PHP can be quite verbose, even when they only perform 
> a simple operation. Partly this is due to a large amount of syntactic 
> boilerplate, and partly due to the need to manually import used variables. 
> This makes code using simple closures hard to read and understand. This RFC 
> proposes a more concise syntax for this pattern. [1]
> 

We can have the discussion again on whether we like short closures or not, but 
it turned out most of internals _and_ userland devs do — based on the vote 
count in the sigle line RFC and the reaction on Nuno's PR, as well as my 
experience from an OSS maintainer point of view.

Furthermore, the `use(*)` syntax misses the point of this proposal: it's not 
about being able to use all variables from the outer scope, it's about a clean 
syntax that's as short as possible — even when you personally disagree that it 
is. I've made the same argument before on this list: it's clear that the PHP 
community _wants_ these changes: named arguments, property promotions, short 
closures, … these are all features that aren't _necessary_, still they are 
great features of a modern-day language. 

I also want to quote from Larry Garfields book on thinking functionally in PHP 
[2], to demonstrate the signicant impact short closures already had today:

> “Combined with PHP’s overall clunky syntax for doing functional-esque code, I 
> generally didn’t go further than “pure functions are your friend,” either in 
> my own code or what I explained to others.
> 
> That is, until PHP 7.4.
> 
> PHP 7.4’s introduction of short lambdas is, as we’ll see in this book, a 
> game-changer. While it doesn’t make anything new possible, it makes a lot of 
> things suddenly practical. That makes all the difference, so I decided it was 
> time to buckle down and really dig into functional programming.”

Larry continues to write a whole book about functional programming in PHP, and 
short closures play a significant role. 

So I hope to see more input on Nuno's PR from a techinical point of view: 
what's missing, what's needed to get this to the RFC phase, … and not only 
discussions about what syntax we like or not, or whether there are other ways 
to solve the same problem. Please provide Nuno with actionable feedback. 

Kind regards
Brent

[1] https://wiki.php.net/rfc/arrow_functions_v2 
 
[2] https://leanpub.com/thinking-functionally-in-php 
 




> On 5 Oct 2020, at 12:39, Andreas Leathley  wrote:
> 
> On 05.10.20 12:15, Deleu wrote:
>> To me that seems like a great argument in favour of the proposal. If you'll
>> want all variables to be imported (which in this case makes completely
>> sense), then `fn() {}` or `fn() => {}` is much less verbose and inline with
>> the mentality to reach for short closures. We reach for short closures to
>> avoid `use()` and convey that the outer process is intertwined with the
>> inner process. `fn()` allows to strengthen the concept that there's no real
>> separation between running SQL stuff in a `callable` that wraps a database
>> transaction.
> 
> Not necessarily: the arrow functions were specifically implemented for
> very short anonymous functions with a return value. Making them more and
> more like the existing "function" syntax would lead to having two
> different ways of defining anonymous functions that mainly differentiate
> themselves by including the parent scope by default or not.
> 
> I like the "function () use (*)" suggestion because it is explicit and
> opt-in. A shorter syntax like "fn () {}" is less clear, and it could
> lead to many people always using fn just because it is faster to write
> (and less to think about), which then could lead to unintended side
> effects because variables are being copied from the parent scope each
> time. When you see a usage of "fn () {}" while reading code you would
> not know if the person used it because it was faster to write, or if the
> parent scope variables are really needed.
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Re: [PHP-DEV] Attributes and strict types

[Brent Roose]

Hi Nikita

From a userland point of view, I'd indeed expect this example to use 
strict_types, because it's declared in UseOfMyAttribute.php. Is this something 
that can be changed still?

Kind regards
Brent

> On 22 Sep 2020, at 14:58, Nikita Popov  wrote:
> 
> Hi internals,
> 
> I would like to clarify how attributes are supposed to interact with
> strict_types. Consider the following code, split up into three files to
> make it clear that each one could have their own strict_types mode:
> 
> MyAttribute.php
>  #[Attribute]
> class MyAttribute {
>public function __construct(string $a) {}
> }
> 
> UseOfMyAttribute.php
>  declare(strict_types=1);
> #[MyAttribute(42)]
> class Test {}
> 
> AccessOfAttribute.php
>  var_dump((new
> ReflectionClass(Test::class'))->getAttributes()[0]->newInstance());
> 
> Currently, what happens is that this code will construct the attribute,
> converting int 42 into string "42", even though UseOfMyAttribute.php has
> strict_types=1.
> 
> My intuitive expectation here would be that we should be following the
> strict_types mode of wherever the attribute is being used (i.e.
> UseOfMyAttribute.php, not MyAttribute.php or AccessOfAttribute.php).
> Currently, we always assume strict_types=0.
> 
> Is my expectation correct?
> 
> Regards,
> Nikita

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

Re: [PHP-DEV] The case for transpiled generics

[Brent Roose]

Hi all

To make myself clear, since I realise I used a confusing term in the subject of 
my mail. What I'm proposing is runtime-erased generics, the way Matthew 
describes them: PHP completely ignores them during runtime, and wouldn't do 
anything with them during compile time. It's up to third party tooling to do 
type checks. And I just want to point out to people who haven't used any static 
analysers in PHP before: they are very_ insightful in knowning what your code 
does, without running it. I don't think there's reason to fear to not checking 
these types at runtime, since static analysis truly takes care of them.

Thanks Matthew for pitching in, I believe the opinion of the ones building and 
maintaining the current static analysis toolset in PHP is essential in this 
discussion.

Kind regards
Brent

> On 17 Sep 2020, at 23:00, Matthew Brown  wrote:
> 
> I think the addition of runtime-erased generics would be a good thing for the 
> language.
> 
> I don’t think PHP should perform any sort of checking of generic parameters 
> at compile time. No other equivalent interpreter performs those compile-time 
> checks, and it’s also *very* complex — since adding support for generics in 
> Psalm I’ve spent the ensuing two years fixing many bugs and filling various 
> holes that have cropped up. Hack, introduced in 2014 and written by bunch of 
> people far smarter than me, had at least one hole in its type-checker’s 
> generics handling that was only patched last year.
> 
> PHP could develop a separate official type-checker to be used alongside its 
> interpreter, similar to Hack’s (hh_check) or TypeScript’s 
> (typescript-checker), but that’s an entirely separate conversation.
> 
> ———
> 
> If this proposal happens, the documentation should make it *super* clear that 
> all generic types are erased at runtime.
> 
> Erased generics would not support code like this:
> 
> ```
> function filter(array $arr) : array {
>$new = [];
>foreach ($arr as $a) {
>if ($a instanceof T) {
>$new[] = $a;
>}
>}
> }
> ```
> 
> Instead PHP would need to support a type classname (or similar) to allow 
> passing generic params explicitly.
> 
> ```
> function filter(array $arr, classname $t_class) 
> : array {
>$new = [];
>foreach ($arr as $a) {
>if ($a instanceof $t_class) {
>$new[] = $a;
>}
>}
> }
> ```
> 
> The implementation would also need a way of denoting covariant (pretty 
> common) and contravariant (very rare) generic parameters, like Hack does.
> 
> 
>> On Sep 17, 2020, at 7:34 AM, Brent Roose  wrote:
>> 
>> Hello internals
>> 
>> Today I'd like to hear your thoughts on what might be a controversial topic, 
>> though I think it's worth having this discussion. I want to make the case 
>> for adding generic syntax, without actually enforing any additional type 
>> checks at runtime. Please hear me out.
>> 
>> We've been discussing generics for years now [1][2], all without any result. 
>> Nikita's latest attempt [3] stalled because, from what I gathered and 
>> amongst other things, doing generic type checks at runtime has a significant 
>> impact on performance.
>> 
>> On the other hand, static analysers have been making their rise for a few 
>> years now. Granted: not the whole community might like this kind of type 
>> strictness, and PHP doesn't force them to; but still projects like PhpStorm 
>> acknowledge their significance — they will add built-in support for both 
>> psalm and PHPStan later this year [4]. Rasmus Lerdorf also showed interest 
>> in the idea of improving PHP's static analysis capabilities two years ago 
>> [5].
>> 
>> That all to say that there's a significant part of the PHP community who's 
>> interested in embracing the benefits of static analysis. 
>> 
>> If we look outside of our PHP bubble, we can see the same thing happening in 
>> JavaScript: the core benefit that TypeScript adds is its robust static 
>> analysis. Sure those developers need an extra compilation step to transpile 
>> their code to plain old JavaScript, but it seems that they are… fine with 
>> that?
>> 
>> I'd like to discuss a similar idea for PHP. If runtime generics aren't 
>> possible because of performance issues, why not explore the other option: 
>> adding generic syntax that is ignored by the interpreter, but can be used by 
>> static analysis tools — third party of built-into PHP, that's another 
>> discussion. I realise this thought goes against the "PHP mindset" we've been 
>> programming with for more than 20 years, but we I think we shouldn'

Re: [PHP-DEV] The case for transpiled generics

[Brent Roose]

Hi Ilija

> On 17 Sep 2020, at 19:01, Ilija Tovilo  wrote:
> 
> Hi Brent
> 
>> Today I'd like to hear your thoughts on what might be a controversial topic, 
>> though I think it's worth having this discussion. I want to make the case 
>> for adding generic syntax, without actually enforing any additional type 
>> checks at runtime. Please hear me out.
> 
> I think having the option to omit runtime type checks could be
> valuable even for non-generic code. If your own internal classes all
> use static analysis the chance of passing a wrong type is pretty low.
> This would probably have to be on a per class or even per function
> basis as you can't reason about other people's code.

I agree, if there's enough interest in this, we might need to consider the 
scope of one or several RFCs.

> 
> I do think we need some form of generic runtime check. If we don't,
> how generics work is completely open to interpretation. Static
> analysis tools copy the behavior of PHP. If PHP has no behavior in
> this regard tools will deviate and generics won't have any real
> meaning at all. There are many nuances to generics (ask Matthew who
> wrote Psalm), we shouldn't underestimate that. With a hybrid approach
> we could also do full type checking in testing environments and
> disable it in more performance critical situations with more
> confidence.

Larry also shared this concern, and I agree that it's important to at least 
have an official spec from the PHP project. Whether part of it should be 
enforced at runtime is up for debate, but it's definitely important.

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

Kind regards
Brent

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

Re: [PHP-DEV] The case for transpiled generics

[Brent Roose]

Hi Matthew and Larry

> On 17 Sep 2020, at 18:21, Larry Garfield  wrote:
> 
> On Thu, Sep 17, 2020, at 10:21 AM, Matthew Brown wrote:
>> Quick thing before I get into my own reaction:
>> 
>> Transpiling is normally thought of as the process of converting one
>> language into another. Tools like Babel transpile TypeScript to JavaScript.

I looked up the definition [1] before writing my mail and it said 

> A […] transpiler is a type of translator that takes the source code of a 
> program written in a programming language as its input and produces an 
> equivalent source code in the same or a different programming language

But I don't want to get stuck on phrasing, if elidiing is the right term as 
Larry suggests, let's go with it!

>> 
>> What's being proposed here (AFAICT) is type erasure – the generic type
>> information would be erased during the conversion to opcodes.
>> 
>> Python (the language) has type erasure for all its types (including its
>> generic types), so no popular Python interpreters check that a function
>> call's argument types match up with the function signature.

I didn't know about Python's approach before, and I think it's validating the 
idea, it's at least something worth looking into.

>> 
>> PHP currently does not erase any types so the opcodes generated by PHP's
>> interpreter include type checks for all the arguments passed to a typed
>> function signature.
>> 
>> Hack follows PHP's model, but erases generic types by default (though has
>> more recently introduced the concept of reified generics) in much the same
>> way you're proposing.
> 
> I concur; this is type elidiing, not transpiling.  Transpiling implies a 
> user-triggered pre-run step.  I know Sara has mused about it before but it's 
> not happened yet.
> 
> Basically what is being proposed (for those who need a concrete example) is 
> you'd write this:
> 
> class Collection {
> 
>  public function add(T $item) { ... }
> 
> }
> $c = new Collection().
> 
> And linters would recognize that, and it would parse, but at runtime it would 
> compile to:
> 
> class Collection {
> 
>  public function add(mixed $item) { ... }
> 
> }
> $c = new Collection().
> 
> 
> And that's the opcodes that would be saved.  (I'm hand-waving a lot here.)
> 
> I would be on board with this, although I would ask if it's possible to 
> provide some compile time checks; I'm thinking LSP validation, which is still 
> relevant for inheritance with generics.  Beyond that, leave the runtime to 
> not enforce it.  (I have no idea how viable that is, but Sara seemed to think 
> it would work so it probably 

I agree that's an approach worth looking into. I didn't want to discuss 
specifics yet, and first get a feel of what people think of the general idea, 
but it's good that you're mentioning this, and I'm glad others are open to the 
idea.

> 
> Another possibility could be to desugar that original to:
> 
> class Collection {
>  public $__T;
> 
>  public function add(mixed $item) {
>if (!$item instanceof $this->__T) {
>  throw new TypeError();
>}
>  }
> }
> $c = new Collection().
> $c->__T == 'Product';
> 
> Which is essentially what you can do in userspace today, but automated.  I 
> don't know how viable that is, but it's another thing to consider.
> 
> --Larry Garfield
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Kind regards
Brent

[1] https://en.wikipedia.org/wiki/Source-to-source_compiler

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

Re: [PHP-DEV] The case for transpiled generics

[Brent Roose]

Hi George

Thanks for the reply!

> On 17 Sep 2020, at 14:34, G. P. B.  wrote:
> 
> Hello Brent,
> 
> I'm going to make the argument I've already done on Reddit once [1], IMHO
> TypeScript is just a nicer pipeline for a preprocessor and a static
> analyser and not a language per say.
> 
> Let me explain with a simpler example than generics, adding immutable
> objects to PHP without native language support using a preprocessor and
> Psalm as the back-end for static-analysis. It would be rather trivial to do
> a search-and-replace of the word immutable and replace it with /**
> @psalm-immutable */ at the (currently non existent) preprocessor level then
> run Psalm and have it shout at you if "you are doing it wrong"TM.
> Now bundle the two tools into a nice CLI command run TypePHP root_of_project
> and voilà support for immutable by just writing
> 
> immutable class Foo {}
> 
> And I'm fairly certain that one can achieve support for generic templates
> in the same way, probably harder than adding support for immutable objects.
> It is also possible to have various back-ends for the static analysers
> which would change the doc-annotation to the one understood by the analyser
> asked.
> 
> Most importantly this can be done purely in PHP and distributed as a
> composer package.
> Therefore needing no support from the language itself, thus this can even
> work in PHP 7.

Preprocessing PHP has been done [1], and the reality is that it didn't work. 
Not because it's technically impossible, but because there's no tooling around 
it: no IDE integration and no static analysis. The pre project actually tried 
developing a plugin for PhpStorm, which failed due to plugin API limitations. 
Tooling and IDEs tend to follow the language spec, because there's no way 
around it. That power lies within the PHP project, and no one else in the 
community has the same amount of influence.

> 
> As such I see no benefit in supporting generics at the language level if
> they don't have any runtime checks.

Like I said in my mail: it's not about being able to achieve a specific kind of 
functionality — static analysers already support generics — it's about giving 
developers an easy, integrated way of writing them, with as less overhead as 
possible. I think most new features added to PHP these days are a testament to 
that mindset — I've already mentioned them in my previous post.

> 
> Best regards
> 
> George P. Banyard
> 
> [1]
> https://www.reddit.com/r/PHP/comments/i9h1v8/considering_php/g1h9umy?context=3

King regards
Brent

[1] https://preprocess.io/#/

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

[PHP-DEV] The case for transpiled generics

[Brent Roose]

Hello internals

Today I'd like to hear your thoughts on what might be a controversial topic, 
though I think it's worth having this discussion. I want to make the case for 
adding generic syntax, without actually enforing any additional type checks at 
runtime. Please hear me out.

We've been discussing generics for years now [1][2], all without any result. 
Nikita's latest attempt [3] stalled because, from what I gathered and amongst 
other things, doing generic type checks at runtime has a significant impact on 
performance.

On the other hand, static analysers have been making their rise for a few years 
now. Granted: not the whole community might like this kind of type strictness, 
and PHP doesn't force them to; but still projects like PhpStorm acknowledge 
their significance — they will add built-in support for both psalm and PHPStan 
later this year [4]. Rasmus Lerdorf also showed interest in the idea of 
improving PHP's static analysis capabilities two years ago [5].

That all to say that there's a significant part of the PHP community who's 
interested in embracing the benefits of static analysis. 

If we look outside of our PHP bubble, we can see the same thing happening in 
JavaScript: the core benefit that TypeScript adds is its robust static 
analysis. Sure those developers need an extra compilation step to transpile 
their code to plain old JavaScript, but it seems that they are… fine with that?

I'd like to discuss a similar idea for PHP. If runtime generics aren't possible 
because of performance issues, why not explore the other option: adding generic 
syntax that is ignored by the interpreter, but can be used by static analysis 
tools — third party of built-into PHP, that's another discussion. I realise 
this thought goes against the "PHP mindset" we've been programming with for 
more than 20 years, but we I think we shouldn't ignore what's happening in the 
PHP- and wider progamming community: static analysis is relevant, whether you 
want to use it or not, and a stricter type system is prefered by many.

Now I know there are alternatives we can use today. Static analysers already 
support generics, using doc blocks. I'm not trying to argue that it's 
impossible to achieve the same results with the toolset we have, but rather 
that there's room for improvement from the developer's point of view. History 
has shown that such convenience additions to PHP have been a difficult pill to 
swallow for some, but on the other hand those kind of changes _have_ been 
happening more and more often anyway: property promotion, short closures, named 
arguments, attributes, yes even types themselves: you can write the same 
working PHP program without any of those features, and yet they have been 
proven so useful and wanted over the last years.

As a sidenote: the idea of transpiling is already present in PHP. Looking at 
constructor property promotion: a purely syntactical feature, which is 
transformed to simpler PHP code at runtime. Nikita called this principle 
"desugaring" in the constructor property promotion RFC [6].

So here's my case for transpiled generics summarized:

- There's no significant runtime performance impact
- The PHP community is already embracing static analysis
- Transpiling has been proved to be a viable workflow, thanks to TypeScript
- As with all things-PHP: it's opt-in. You don't have to use the syntax if you 
don't want to and you won't experience any downsides

So with all that being said, I'm looking forward to hearing your thoughts. 

Kind regards
Brent

[1] https://wiki.php.net/rfc/generics  
[2] https://wiki.php.net/rfc/generic-arrays 
 
[3] https://github.com/PHPGenerics/php-generics-rfc/issues/45 
 
[4] 
https://blog.jetbrains.com/phpstorm/2020/07/phpstan-and-psalm-support-coming-to-phpstorm/
 

 
[5] https://externals.io/message/101477#101592 
 
[6] https://wiki.php.net/rfc/constructor_promotion#desugaring 
 

Re: [PHP-DEV] PHP 8.0 branch cut

[Brent Roose]

Hey Dmitiry

Speaking of the JIT. I remember berblei mentioning that the JIT configuration 
options were going to change prior to the final 8 release 
(https://www.reddit.com/r/PHP/comments/hjxlh9/jit_benchmarks_on_reallife_web_applications/fwuje8g/
 
).
 In other words: not one value with several integer flags, but dedicated 
options for every configuration entry. Is this still on the roadmap?

Kind regards
Brent

> On 15 Sep 2020, at 07:05, Dmitry Stogov  wrote:
> 
> This also gives me a time frame to clean up JIT code without hurry.
> I plan to separate the common JIT code, and merge JIT and VM helpers.
> 
> Thanks. Dmitry.
> 
> On Mon, Sep 14, 2020 at 5:55 PM Sara Golemon  wrote:
> 
>> On Mon, Sep 14, 2020 at 9:39 AM Nikita Popov  wrote:
>> 
>>> On Fri, Sep 11, 2020 at 6:49 PM Sara Golemon  wrote:
>>> 
 Next Tuesday, Sep 15th, has been marked on my calendar as the branch
>> date
 for PHP-8.0 which would open master up for 8.1 targeted work.
 
 This would mean that bug fixes would need to include PHP-8.0 in their
 merge
 chain (meaning more work to merge 8.0 targeted fixes).
 
 Please let Gabriel and I know how you feel about this date.  I can see
 that
 master is still quite active, and I don't wish to make the work to
 stablize
 the 8.0 release any more difficult than it has to be.
 
 
>>> 
>>> I think it would be good to make this week's release beta4 rather than
>> rc1
>>> (without affecting the rest of the schedule). In that case we'd also push
>>> back the branching and final ABI freeze two weeks.
>>> 
>>> We're close to done with the warning to Error exception promotion task,
>>> but haven't really started on reviewing and consolidating parameter names
>>> yet (in preparation for named parameters). It would be good to have that
>>> work mostly finalized before RC1, so we can limit the number of nominally
>>> BC-breaking changes past RC1 (I expect we'll still fix some things that
>>> slipped through the cracks, but at least we should prevent any mass
>>> changes).
>>> 
>>> 
>> Yep. This seems like a reasonable adjustment to the schedule in order to
>> finalize these features.  I'll do beta4 tomorrow/thursday, and we should
>> plan for RC1 branching in two weeks.  Wiki (
>> https://wiki.php.net/todo/php80 )
>> has been updated to reflect this.  Note that I have NOT moved the GA date
>> at this time, as that would push us into Dec 10th.  Though as the date
>> approaches we may decide to add RC5 back in for safety despite the
>> perinavidinal timing.
>> 
>> -Sara
>> 
>> P.S. Yes, I made that word up. You know which one.
>> 

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Brent Roose]

Hi all

I want to point out the use-case when you're using CS tools, static analysers 
and IDEs: they report unused variables as errors. There are ways around those 
errors, but it's more convenient if there's language support. I'd say that 
conceptually it's also more correct: if you're not using a variable, it 
shouldn't be there.

As some of you have shown, there are ways achieve the same result without 
adding new syntax. Just like we didn't need short closures and keep using the 
normal closure syntax, like we could write if statements and didn't need the 
nullsafe operator, like we didn't need named arguments or constructor property 
promotion. I think the past years of PHP devlopment have shown that the 
majority likes convenient langague syntax and constructs, not because it's 
absolutely necessary, but because it's just a little more clean, a little less 
verbose, a bit more convenient.

PHP has been maturing over the last years, which means there's room, and need, 
for things that aren't strictly necessary.

Kind regards
Brent

> On 3 Sep 2020, at 09:18, Stanislav Malyshev  wrote:
> 
> Hi!
> 
>> If it adds a micro-optimization, great, but allowing a developer to
>> explicitly signal intent is the primary argument for adding void.
>> IMO.
> 
> You can signal intent by using $_ or $dummy or whatever. You don't need
> new language construct each time for each way of using or not using a
> variable.
> 
> -- 
> Stas Malyshev
> smalys...@gmail.com
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Re: [PHP-DEV] Community vote on RFCs

[Brent Roose]

Hi Kalle, all

> Anyone who is not actively involved with the PHP project, is not
> someone I can feel safe with granting the right to vote. 

Just want to point out that there are lots of people eligable to vote who are 
not actively involved with PHP development at the moment. There has even been a 
few occasions lately where I tweet about my point of view on an RFC which has 
been in voting phase for over a week, and suddenly someone replies "Oh that's 
interesting, I'll vote for that later today". In other words: a tweet from a 
random userland developer reminded someone to vote.

What about people who occasionaly contribute to docs? Are they more eligable to 
vote than someone like Nicalos Grekas? It's a good thing he got voting rights, 
but in my mind that should have been a no-brainer. I realise some people might 
get upset with this point of view, but I don't think that occasionaly 
contributing to PHP docs makes you a better representative than having actively 
shaped the PHP landscape over the past decade.

How many people have voting rights? Over 200 if I'm not mistaken? How many of 
those have been activly contributing to PHP for over the past year? I think 
that's a better question to answer. If half of those people's voting rights get 
revoked then maybe there's room to allow a few more key community figures to 
participate?

> I very much agree with Stas here.

I agree too btw. There's no need for official community polls, I feel like the 
key figures of PHP's core team already do listen to the community. 

Kind regards
Brent

> On 20 Aug 2020, at 15:48, Kalle Sommer Nielsen  wrote:
> 
> Den tor. 20. aug. 2020 kl. 01.07 skrev Stanislav Malyshev 
> :
>> Please feel welcome to. However, I don't think this should have any
>> official role in any PHP governance process, any more than any other
>> poll on the internet might. That said, my opinion is hearing other
>> opinions is rarely harmful and frequently useful, so why not.
> 
> I very much agree with Stas here. I think it should be up to the
> individual RFC author to put out feelers for feedback from userland,
> because going to internals is the final judgement.
> 
> 
> 
> Regarding the link to the thread in the initial email, while it is not
> impossible to get voting rights. There is a very high barrier of
> entry, if you are not involved with the PHP project, then being
> granted voting rights is absurd and can easily flood the usual Core
> Developer voting turnout, we had a similar debate about this in the
> spring of 2019 in regards to the PHP FIG which was heavily disputed.
> 
> Anyone who is not actively involved with the PHP project, is not
> someone I can feel safe with granting the right to vote. Should I also
> gain the right at any PHP based project to vote on whatever democratic
> process they have because I am a maintainer of PHP? No I shouldn't. If
> I'm involved with a project in question, then that changes the
> perspective but it is still up to the project to decide on how to
> proceed here.
> 
> -- 
> regards,
> 
> Kalle Sommer Nielsen
> ka...@php.net
> 
> -- 
> 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

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Brent Roose]

Doesn't it make the most sense to re-vote the syntax? I'd consider the previous 
vote to be invalid given the parsing issues that weren't listed in the RFC.

A re-vote seems the most fair: if the majority still prefers @@, then so be it. 
Otherwise the syntax changes once again, before feature-freeze. I suppose the 
RMs should have a final say in this descision?

Kind regards
Brent

> On 22 Jul 2020, at 14:46, Benjamin Eberlei  wrote:
> 
> On Wed, Jul 22, 2020 at 2:40 PM Deleu  wrote:
> 
>> "Terrible" is the amount of humans having their lives taken by a pandemic.
>> This is at most slightly inconvenient for you. The aggressive tone in this
>> discussion is extremely unnecessary.
>> 
> 
> After the RFC was voted on for @@, objectively "terrible" (or bad) reasons
> for this patch have been found though, that can only be softened by
> changing token parsing for namespaces.
> 
> This is not a subjective opinion.
> 
> 
>> On Wed, Jul 22, 2020 at 2:00 PM Derick Rethans  wrote:
>> 
>>> Hi all,
>>> 
>>> I know we've voted twice on this already, but are we really sure that
>>> the @@ syntax is a good idea?
>>> 
>>> - There are lots of grumbles, both on here, room 11, as well as in the
>>>  wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/)
>>> - It has the distinct possibility to cause further parsing issues, akin
>>>  to what ended up happening with what Nikita is addressing at
>>>  https://wiki.php.net/rfc/namespaced_names_as_token
>>> - There is no "end symbol" to make finding occurences easier.
>>> - It is a syntax *no other language* uses.
>>> - @ is never going to go away, so the possibility of @@ moving to @ is
>>>  also 0.
>>> 
>>> Please, let's do the sensible and use the Rusty #[...] syntax.
>>> 
>>> cheers,
>>> Derick
>>> 
>>> --
>>> PHP 7.4 Release Manager
>>> Host of PHP Internals News: https://phpinternals.news
>>> Like Xdebug? Consider supporting me: https://xdebug.org/support
>>> https://derickrethans.nl | https://xdebug.org | https://dram.io
>>> twitter: @derickr and @xdebug
>>> 
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: https://www.php.net/unsub.php
>>> 
>>> 
>> 
>> --
>> Marco Aurélio Deleu
>> 

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

Re: [PHP-DEV] Changing default assertion mode to throw exceptions

[Brent Roose]

Hi Levi

I personally almost never use assert, and actually assumed it would throw an 
error, so this sounds like a good change! 

Have you done research on how this would affect the top-1000-ish popular 
packages like Nikita does?

Kind regards
Brent

> On 20 Jul 2020, at 15:48, Levi Morrison via internals 
>  wrote:
> 
> On Mon, Jul 13, 2020 at 11:37 AM Levi Morrison  wrote:
>> 
>> Hello everyone,
>> 
>> I'd like to change the default mode of assertion failures to throw.
>> The current default is to warn. In my opinion this is a bad strategy:
>> the engine asserted that something that is expected to be true is not,
>> so executing further is a bad idea. This leaves throwing or bailing
>> out. I think throwing an exception is better than bailing out, so
>> that's what I propose.
> 
> Hello, everyone. It's been a week and I have only heard a bit of
> positive feedback and no pushback. Anyone else want to reply?
> 
> -- 
> 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

Re: [PHP-DEV] [RFC] Saner string to number comparisons

[Brent Roose]

Hey Nikita

Thanks for the rebase. I just tested this on one of our most largest projects 
(after verifying that the warning does show in a dummy test case), and all is 
fine. So from my point of view, there is a theoretical chance of breaking code, 
but I believe this won't have a large impact, at least not on modern-day 
projects.

Kind regards
Brent

> On 15 Jul 2020, at 11:10, Nikita Popov  wrote:
> 
> On Wed, Jul 15, 2020 at 10:56 AM Brent Roose  <mailto:bre...@stitcher.io>> wrote:
> 
>> Hi Nikita
>> 
>> Yes that would be nice, if it's not too much of a hassle. I'm only able to
>> test this in one or two large Laravel projects, so it would still be a
>> limited test.
>> 
>> Kind regards
>> Brent
>> 
> 
> Done! https://github.com/php/php-src/pull/3917 
> <https://github.com/php/php-src/pull/3917> is now based on current 7.4
> HEAD. Note that it just unconditionally throws a warning, without a way to
> disable it.
> 
> Nikita
> 
>> On 15 Jul 2020, at 10:53, Nikita Popov > <mailto:nikita@gmail.com>> wrote:
>> 
>> On Wed, Jul 15, 2020 at 10:49 AM Brent Roose > <mailto:bre...@stitcher.io>> wrote:
>> 
>>> Hi Nikita
>>> 
>>> Is the ini setting available in current 7.4 builds? Is it documented
>>> somewhere? I'd like to test this change in some of our projects.
>>> 
>> 
>> We did not introduce an ini setting in PHP 7.4, I only used it for my own
>> experiments. The implementation is available at
>> https://github.com/php/php-src/pull/3917 
>> <https://github.com/php/php-src/pull/3917>. I could rebase that to current
>> 7.4 if that would be useful.
>> 
>> Nikita
>> 
>>> On 15 Jul 2020, at 10:28, Nikita Popov >> <mailto:nikita@gmail.com>> wrote:
>>> 
>>> On Tue, Jul 14, 2020 at 11:47 PM Björn Larsson >> <mailto:bjorn.x.lars...@telia.com>
>>>> 
>>> wrote:
>>> 
>>> Den 2020-07-14 kl. 15:48, skrev Nikita Popov:
>>> 
>>> On Thu, Jul 2, 2020 at 10:09 AM Nikita Popov >> <mailto:nikita@gmail.com>>
>>> 
>>> wrote:
>>> 
>>> 
>>> On Mon, Mar 4, 2019 at 6:00 PM Nikita Popov >> <mailto:nikita@gmail.com>>
>>> 
>>> wrote:
>>> 
>>> 
>>> On Wed, Feb 27, 2019 at 10:23 AM Zeev Suraski >> <mailto:z...@php.net>> wrote:
>>> 
>>> 
>>> On Tue, Feb 26, 2019 at 2:27 PM Nikita Popov >> <mailto:nikita@gmail.com>>
>>> wrote:
>>> 
>>> Hi internals,
>>> 
>>> I think it is well known that == in PHP is a pretty big footgun. It
>>> doesn't
>>> have to be. I think that type juggling comparisons in a language like
>>> PHP
>>> have some merit, it's just that the particular semantics of == in PHP
>>> make
>>> it so dangerous. The biggest WTF factor is probably that 0 ==
>>> 
>>> "foobar"
>>> 
>>> returns true.
>>> 
>>> I'd like to bring forward an RFC for PHP 8 to change the semantics
>>> 
>>> of ==
>>> 
>>> and other non-strict comparisons, when used between a number and a
>>> string:
>>> 
>>> https://wiki.php.net/rfc/string_to_number_comparison 
>>> <https://wiki.php.net/rfc/string_to_number_comparison>
>>> 
>>> The tl;dr is that if you compare a number and a numeric string,
>>> 
>>> they'll
>>> 
>>> be
>>> compared as numbers. Otherwise, the number is converted into a string
>>> and
>>> they'll be compared as strings.
>>> 
>>> This is a very significant change -- not so much because the actual
>>> 
>>> BC
>>> 
>>> breakage is expected to be particularly large, but because it is a
>>> silent
>>> change in core language semantics, which makes it hard to determine
>>> whether
>>> or not code is affected by the change. There are things we can do
>>> 
>>> about
>>> 
>>> this, for example the RFC suggests that we might want to have a
>>> transition
>>> mode where we perform the comparison using both the old and the new
>>> semantics and warn if the result differs.
>>> 
>>> I think we should give serious consideration to making such a change.
>>> I'd
>>> be interested to hear whether other people think this is worthwhile,
>>> 
>>> and
>>> 
>>> how 

Re: [PHP-DEV] [RFC] Saner string to number comparisons

[Brent Roose]

Hi Nikita

Yes that would be nice, if it's not too much of a hassle. I'm only able to test 
this in one or two large Laravel projects, so it would still be a limited test.

Kind regards
Brent

> On 15 Jul 2020, at 10:53, Nikita Popov  wrote:
> 
> On Wed, Jul 15, 2020 at 10:49 AM Brent Roose  <mailto:bre...@stitcher.io>> wrote:
> Hi Nikita
> 
> Is the ini setting available in current 7.4 builds? Is it documented 
> somewhere? I'd like to test this change in some of our projects.
> 
> We did not introduce an ini setting in PHP 7.4, I only used it for my own 
> experiments. The implementation is available at 
> https://github.com/php/php-src/pull/3917 
> <https://github.com/php/php-src/pull/3917>. I could rebase that to current 
> 7.4 if that would be useful.
> 
> Nikita
>> On 15 Jul 2020, at 10:28, Nikita Popov > <mailto:nikita@gmail.com>> wrote:
>> 
>> On Tue, Jul 14, 2020 at 11:47 PM Björn Larsson > <mailto:bjorn.x.lars...@telia.com>>
>> wrote:
>> 
>>> Den 2020-07-14 kl. 15:48, skrev Nikita Popov:
>>>> On Thu, Jul 2, 2020 at 10:09 AM Nikita Popov >>> <mailto:nikita@gmail.com>>
>>> wrote:
>>>> 
>>>>> On Mon, Mar 4, 2019 at 6:00 PM Nikita Popov >>>> <mailto:nikita@gmail.com>>
>>> wrote:
>>>>> 
>>>>>> On Wed, Feb 27, 2019 at 10:23 AM Zeev Suraski >>>>> <mailto:z...@php.net>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Tue, Feb 26, 2019 at 2:27 PM Nikita Popov >>>>>> <mailto:nikita@gmail.com>>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hi internals,
>>>>>>>> 
>>>>>>>> I think it is well known that == in PHP is a pretty big footgun. It
>>>>>>>> doesn't
>>>>>>>> have to be. I think that type juggling comparisons in a language like
>>>>>>>> PHP
>>>>>>>> have some merit, it's just that the particular semantics of == in PHP
>>>>>>>> make
>>>>>>>> it so dangerous. The biggest WTF factor is probably that 0 ==
>>> "foobar"
>>>>>>>> returns true.
>>>>>>>> 
>>>>>>>> I'd like to bring forward an RFC for PHP 8 to change the semantics
>>> of ==
>>>>>>>> and other non-strict comparisons, when used between a number and a
>>>>>>>> string:
>>>>>>>> 
>>>>>>>> https://wiki.php.net/rfc/string_to_number_comparison 
>>>>>>>> <https://wiki.php.net/rfc/string_to_number_comparison>
>>>>>>>> 
>>>>>>>> The tl;dr is that if you compare a number and a numeric string,
>>> they'll
>>>>>>>> be
>>>>>>>> compared as numbers. Otherwise, the number is converted into a string
>>>>>>>> and
>>>>>>>> they'll be compared as strings.
>>>>>>>> 
>>>>>>>> This is a very significant change -- not so much because the actual
>>> BC
>>>>>>>> breakage is expected to be particularly large, but because it is a
>>>>>>>> silent
>>>>>>>> change in core language semantics, which makes it hard to determine
>>>>>>>> whether
>>>>>>>> or not code is affected by the change. There are things we can do
>>> about
>>>>>>>> this, for example the RFC suggests that we might want to have a
>>>>>>>> transition
>>>>>>>> mode where we perform the comparison using both the old and the new
>>>>>>>> semantics and warn if the result differs.
>>>>>>>> 
>>>>>>>> I think we should give serious consideration to making such a change.
>>>>>>>> I'd
>>>>>>>> be interested to hear whether other people think this is worthwhile,
>>> and
>>>>>>>> how we could go about doing it, while minimizing breakage.
>>>>>>>> 
>>>>>>> I generally like the direction and think we should seriously consider
>>> it.
>>>>>>> 
>>>>>>> I think that before we make any decisions on this, or even dive too
>>> deep
>>>

Re: [PHP-DEV] [RFC] Saner string to number comparisons

[Brent Roose]

Hi Nikita

Is the ini setting available in current 7.4 builds? Is it documented somewhere? 
I'd like to test this change in some of our projects.

Kind regards
Brent

> On 15 Jul 2020, at 10:28, Nikita Popov  wrote:
> 
> On Tue, Jul 14, 2020 at 11:47 PM Björn Larsson  >
> wrote:
> 
>> Den 2020-07-14 kl. 15:48, skrev Nikita Popov:
>>> On Thu, Jul 2, 2020 at 10:09 AM Nikita Popov 
>> wrote:
>>> 
 On Mon, Mar 4, 2019 at 6:00 PM Nikita Popov 
>> wrote:
 
> On Wed, Feb 27, 2019 at 10:23 AM Zeev Suraski  wrote:
> 
>> 
>> On Tue, Feb 26, 2019 at 2:27 PM Nikita Popov 
>> wrote:
>> 
>>> Hi internals,
>>> 
>>> I think it is well known that == in PHP is a pretty big footgun. It
>>> doesn't
>>> have to be. I think that type juggling comparisons in a language like
>>> PHP
>>> have some merit, it's just that the particular semantics of == in PHP
>>> make
>>> it so dangerous. The biggest WTF factor is probably that 0 ==
>> "foobar"
>>> returns true.
>>> 
>>> I'd like to bring forward an RFC for PHP 8 to change the semantics
>> of ==
>>> and other non-strict comparisons, when used between a number and a
>>> string:
>>> 
>>> https://wiki.php.net/rfc/string_to_number_comparison
>>> 
>>> The tl;dr is that if you compare a number and a numeric string,
>> they'll
>>> be
>>> compared as numbers. Otherwise, the number is converted into a string
>>> and
>>> they'll be compared as strings.
>>> 
>>> This is a very significant change -- not so much because the actual
>> BC
>>> breakage is expected to be particularly large, but because it is a
>>> silent
>>> change in core language semantics, which makes it hard to determine
>>> whether
>>> or not code is affected by the change. There are things we can do
>> about
>>> this, for example the RFC suggests that we might want to have a
>>> transition
>>> mode where we perform the comparison using both the old and the new
>>> semantics and warn if the result differs.
>>> 
>>> I think we should give serious consideration to making such a change.
>>> I'd
>>> be interested to hear whether other people think this is worthwhile,
>> and
>>> how we could go about doing it, while minimizing breakage.
>>> 
>> I generally like the direction and think we should seriously consider
>> it.
>> 
>> I think that before we make any decisions on this, or even dive too
>> deep
>> into the discussion - we actually need to implement this behavior,
>> including the proposed INI setting you mentioned we might add in 7.4
>> - and
>> see what happens in some real world apps, at least in terms of
>> potential
>> danger (as you say, figuring out whether there's actual breakage would
>> require a full audit of every potentially problematic sample.
>> Ultimately,
>> I think there's no question that if we were to start from scratch,
>> we'd be
>> going for something along these lines.  But since we're not starting
>> from
>> scratch - scoping the level of breakage is key here.
>> 
>> Zeev
>> 
> Totally agree that assessing the amount of breakage in real code is key
> here. I have now implemented a warning for PHP 7.4 (for now
>> unconditional,
> no ini setting) that is thrown whenever the result of a comparison is
>> going
> to change under the currently proposed rules:
> https://github.com/php/php-src/pull/3917
> 
> I've done a few initial tests by running this against the Laravel,
> Symfony and pear-core. The warning was thrown 2 times for Laravel, 1
>> times
> for Symfony and 2 times for pear-core. (See PR for the results.)
> 
> Both of the warnings in pear-core pointed to implementation bugs. The
> Symfony warning was due to trailing whitespace not being allowed in
>> numeric
> strings (something we should definitely change). One of the Laravel
> warnings is ultimately a false-positive (does not change behavior),
>> though
> code could be improved to avoid it. I wasn't able to tell whether the
>> other
> one is problematic, as it affects sorting order.
> 
> I have to say that this is a lot less warnings than I expected. Makes
>> me
> wonder if I didn't make an implementation mistake ^^
> 
> Regards,
> Nikita
> 
 As we're moving closer to PHP 8 feature freeze, I want to give this RFC
>> a
 bump. I've updated the text to account for some changes that have
>> happened
 in the meantime, such as the removal of locale-sensitivity for float to
 string conversions.
 
 It's been quite a while since we discussed this last, and back then the
 discussion was fairly positive. Some experiments with a warning mode
>> also
 showed that the impact, at least in framework/library code, appears to
>> be
 fairly low in practice, contrary 

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

[Brent Roose]

Hi Nikita

What happens to the attributes syntax if this RFC doesn't pass?

Furthermore, I think voting against this RFC to prevent the @@ syntax from 
happening is an abuse of the system. If there are problems with the attribute 
syntax, than the vote results on that one should be called void and a revote 
should happen, but it shouldn't affect the vote of this RFC, which has a larger 
impact than just the attributes syntax.

Kind regards
Brent



> On 14 Jul 2020, at 11:09, Nikita Popov  wrote:
> 
> On Thu, Jul 9, 2020 at 4:33 PM Nikita Popov  > wrote:
> 
>> 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.
>>> 
>> 
>> I have reduced the scope of this RFC to handle just the issue of
>> namespaced names, without touching any other reserved keyword restrictions.
>> As the discussion shows, those are trickier, with more cases of perceived
>> ambiguity that may need to be mitigated.
>> 
>> As this proposal is now a prerequisite for
>> https://wiki.php.net/rfc/shorter_attribute_syntax, I have heard from a
>> disturbing number of people that they might vote against this proposal, not
>> because they disagree with it, but because that would prevent the adoption
>> of the @@ attribute syntax. I'm not sure what to do about that...
>> 
> 
> Heads up: I plan to open voting on this proposal tomorrow, unless there is
> further feedback.
> 
> Nikita

Re: [PHP-DEV] Typed array properties V2

[Brent Roose]

Hello all

It's a much-requested feature for years and years. My first thought was "we 
need generics, not this" but than I took 5 minutes to actually think about it. 
While the same, and much more, can be achieved with generics, it's a difficult 
feature to implement. There have been several RFCs for generics in the past, 
which failed. I know Levi Morisson was, at one point, looking at adding support 
for generics only in traits, because it's difficult to add them in other places.

While I still think generics would be a great feature, I now also believe it's 
worth looking at an "array of" type as something standalone. I've got no clue 
about the technical implications, but maybe suprting "array of" syntax is a lot 
more easy than full blown generics? Looking at my day to day work with PHP, 
I'dsay "array of" types would solve ~80% of my problems with PHP's current type 
system, and I figure there are lots of developers in a similar situation. If I 
remember correct from my college days, Java also supports both styles: Int[] 
and ArrayList.

All that to say that maybe it's worth the effort looking at "array of" types as 
something different than generics?

Kind regards
Brent

> On 17 Jan 2020, at 08:50, Aran Reeks  wrote:
> 
> Hi Internals,
> 
> I'd like to kick off a conversation to capture everyone else's thoughts on
> tweaking / improving typed properties for arrays (for a PHP 8.x release).
> 
> With all the work done lately to greatly improve the type support in PHP
> (which is amazing by the way), I'm finding for the most part, I'm no longer
> needing to Docblock as much of my code which is lovely.
> 
> That said, there's a common use case that keeps me going back to them which
> I think would be a good thing for PHP to try and solve as a language
> feature - better typing of arrays to type their properties.
> 
> IDEs like PHPStorm handle this structure already hence sticking to that as
> a starting point...
> 
> @returns []int
> 
> This would designate the return of an array where all its keys are that of
> the int type, but it works for any type.
> 
> With that in mind, it might also make sense to allow a shorthand array
> alias for array types anyway - array -> [].
> 
> To use actual PHP examples, this would mean the following would be
> supported:
> 
> // Typed array properties ...values would follow any existing PHO type
> function returnsIntArray(): []int;
> function returnsClassArray(): []Class;
> 
> // The same outcome
> function returnsArray(): array;
> function returnsArray(): [];
> 
> I welcome all your thoughts on this proposal.
> 
> Many thanks,
> Aran

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

Re: [PHP-DEV] Re: VCS Account Request: nicolasgrekas

[Brent Roose]

Hi Peter

Isn't it strange that someone like Nicolas doesn't get a vote? Symfony has such 
a large impact on the PHP community, and Nicolas has such a large impact on its 
development. Meanwhile people who contribute to the PHP docs, sometimes 
completely estranged from modern day-to-day PHP development do have a vote.

What are the rules here? According to the wiki it's this:

> There's no way around this 'small' issue. Changes made to the PHP language 
> will affect millions of people, and theoretically, each and every one of them 
> should have a say in what we do. For obvious reasons, though, this isn't a 
> practical approach.
> 
> The proposal here is for two audiences to participate in the voting process:
> 
>   • People with php.net VCS accounts that have contributed code to PHP
>   • Representatives from the PHP community, that will be chosen by those 
> with php.net VCS accounts
>   • Lead developers of PHP based projects (frameworks, cms, 
> tools, etc.)
>   • regular participant of internals discussions


I would think Nicolas' application would at least require a vote before being 
denied?

Kind regards
Brent

> On 14 Jan 2020, at 14:08, Peter Cowburn  wrote:
> 
> On Tue, 14 Jan 2020 at 12:27, Nicolas Grekas 
> wrote:
> 
>> Le mar. 14 janv. 2020 à 13:20, PHP Group  a écrit :
>> 
>>> VCS Account Rejected: nicolasgrekas rejected by salathe /o\
>>> 
>> 
>> So, what's the process to get a vote now?
>> Do I need sponsor? Something else?
>> 
> 
> Hi,
> 
> While the notion of community representative votes was documented at the
> time of the RFC process introduction, it is not something that is supported
> by the project.
> Please become an active contributor to this project: in particular active
> enough to get yourself a PHP.net VCS account. One of the (many!) benefits
> of doing so is being granted RFC voting privileges.
> 
> Regards,
> Peter

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

[PHP-DEV] --with-libxml-dir and libxml headers on MacOS

[Brent Roose]

Hello internals

The upgrading guide lists that the option --with-libxml-dir is removed in PHP  
7.4 (https://github.com/php/php-src/blob/PHP-7.4/UPGRADING#L763 
). Unfortunately on 
MacOS, header files are not stored in the usual locations, which means that 
compiling PHP fails with the following error: fatal error: 'libxml/parser.h' 
file not found

With the removal of --with-libxml-dir, I wonder what the right way is to tell 
PHP where the header files are located.

As a sidenote: some might suggest using the built-in MacOS tool to install the 
header files in /usr/include 
(https://silvae86.github.io/sysadmin/mac/osx/mojave/beta/libxml2/2018/07/05/fixing-missing-headers-for-homebrew-in-mac-osx-mojave/
 
),
 though this tool doesn't seem to work anymore in recent MacOS versions.

Kind regards
Brent

Re: [PHP-DEV] [VOTE] Object Initializer

[Brent Roose]

Hi Michał

I can't help but wonder: why did you start the vote to begin with? It seemed to 
me that, based on the discussion feedback, it would never pass in its current 
form.

Kind regards
Brent

> On 24 Oct 2019, at 09:41, Michał Brzuchalski  
> wrote:
> 
> Hi all,
> 
> I've closed the vote. Object Initializer RFC failed with 26 votes against
> and only 3 in favour.
> The second vote has a meaning only for future revive of this feature.
> The majority decided that the preferred assign token should be eq "=".
> 
> Thanks to all for taking a vote.
> 
> Cheers,
> Michał Brzuchalski
> 
> pon., 7 paź 2019 o 13:00 Michał Brzuchalski 
> napisał(a):
> 
>> Hi all,
>> 
>> the discussion period was long and discussion I think quite comprehensive.
>> 
>> The RFC is at https://wiki.php.net/rfc/object-initializer and is up for
>> voting now.
>> The voting will take 2 weeks from 11:00 UTC 7th till 11:00 UTC 21st of
>> October 2019.
>> 
>> BR,
>> Michał Brzuchalski
>> 

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