Re: [PHP-DEV] Proposal: AS assertions

[Matthew Brown]

>
> What's the advantage of a language construct over the following?
>
> ```php
> /**
>  * @template T of object
>  * @psalm-assert T $value
>  * @param class-string $type
>  */
> function as(mixed $value, string $type): mixed
> {
> if (! $value instanceof $type) { throw
> SomeKindOfException::forMismatchingRequirements($value, $type); }
>
> return $value;
> }
>
> echo as(myExpression(), MyType::class)->methodOfMyType();
> ```
>
>
A static analysis tool supporting something in docblocks should not
preclude those things being added in syntax IMO.

Hack's `as` operator is very neat, and it'd be trivial for existing SA
tools to support the same in PHP.

Here's a demo of `as` in Hack getting flagged by a SA tool:
https://hakana.dev/#XQAAgAA2AAAzHUn_qWH7EwabJzyN0tdfxv3ug6f7oZ-qScnamcl1qjUZCPmuKA3tD-KFr1f0ZPcrAXt_D1L___KsQAA%3D

This would also benefit from a `nonnull` subtype of `mixed` which could be
used as a null refinement.

Re: [PHP-DEV] [RFC] Property hooks, nee accessors

[Matthew Brown]

>
> Regarding $field vs. $this->propName, there's a few reasons we went that
> route.


Overall I think this is a really good proposal, but you might want to
consider a second vote for that particular syntax.

`$field` vs `$this->propName` feels a little magical. It's a simpler magic
than actual magic methods — it's magic that static analysis tools can
quickly reason about (as they can with promoted properties).

But I can imagine developers coming across this particular syntax in a PR
and thinking "that looks like a bug".

I know it's a few extra keypresses, but I think $this->propName is easier
to scan, and more familiar (given this RFC introduces a lot of other new
syntax).

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Matthew Brown]

On Mon, 15 Nov 2021 at 17:32, Chase Peeler  wrote:

>
>
> On Mon, Nov 15, 2021 at 4:40 PM Matthew Brown 
> wrote:
>

>
>> I encourage people to vote "yes" on this, if you want PHP to be better at
>> preventing people from shooting themselves in the foot.
>
>
> What if I want a language where people can shoot themselves in the foot
> because the flexibility it offers is what makes it great
>

I don't think this particular feature makes PHP great, and I don't think
the active PHP community thinks that either.

I know there are
>> valid uses for this, but it's nevertheless a surprising feature, and not
>> one that delights many PHP developers.
>
>
> Why is this surprising? It's been available since classes were introduced
> to PHP.
>

Not everyone who uses PHP has been using it since time immemorial. Some of
us came from compiled languages where this behaviour is expressly
prohibited, while others are used to interpreted languages that  also
prohibit this behaviour.

This is what I mean by surprising: I have heard newcomers express literal
surprise when discovering this for the first time, and not in a delighted
way.

Best wishes,

Matt

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Matthew Brown]

On Fri, 12 Nov 2021 at 08:08, Nikita Popov  wrote:

> Hi internals,
>
> I've opened the vote on
> https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> 2021-11-26.
>
> Regards,
> Nikita
>

There are two things developers think about when releasing code:

1. does it work for me
2. does it work for everyone else

With its support for runtime type hints and other similar checks, PHP does
a reasonably good job of aligning those two — what works for me _generally_
works for everyone else, too.

Using dynamic properties is one of the areas where "works for me" and
"works for everyone else" can diverge. Some people use static analysis to
keep track of those divergences, but if PHP _can_ warn people they're doing
a probably-dumb thing, I think it should.

I encourage people to vote "yes" on this, if you want PHP to be better at
preventing people from shooting themselves in the foot. I know there are
valid uses for this, but it's nevertheless a surprising feature, and not
one that delights many PHP developers. Making it attribute-only from 9.0
onwards seems incredibly sensible.

Best wishes,

Matt

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Matthew Brown]

On Sat, 18 Sept 2021 at 12:04, Larry Garfield 
wrote:

>
> I am frequently on-record hating on PHP arrays, and stating that I want
> something better.  The problems with PHP arrays include:
>
> 1. They're badly performing (because they cannot be optimized)
> 2. They're not type safe
> 3. They're mutable
> 4. They mix sequences (true arrays) with dictionaries/hashmaps, making
> everything uglier
> 5. People keep using them as structs, when they're not
> 6. The API around them is procedural, inconsistent, and overall gross
> 7. They lack a lot of native shorthand operations found in other languages
> (eg, slicing)
> 8. Their error handling is crap
>
> Any new native/stdlib alternative to arrays needs to address at least half
> of those issues, preferably most/all.
>

Hey Larry,

I believe 1. and 2. are an impossible standard for any PHP-based proposal
to meet. If you want it to be (runtime) type-safe, that assumes the
existence of runtime type checks which can quickly become a performance
bottleneck.

For 3, having explored immutability in depth with Psalm, arrays don't
present any sort of challenge due to their copy-on-write behavior. There's
a chunk of Psalm's codebase that makes heavy use of arrays, and it's
still provably pure.

5: they're used as makeshift structs, but there's nothing preventing people
using constructor property promotion and named parameters to model the same
data. I think this is effectively a solved problem.

No real debates about the 4, 6, 7 and 8, but I'm radically opposed to
throwing out the baby with the bathwater here — languages that have solved
these problems exist, but demanding a proposal pass a purity test means the
PHP project is more likely to stay the way it is.

Best wishes,

Matt

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Matthew Brown]

I can also give some in-the-trenches perspective of vec's utility, having
spent the last month and a half writing Hack. vec is a really useful data
structure to be able to use explicitly in code. It makes code that uses it
easier to understand.

The main benefit over Vector is that it could be used as a straightforward
replacement for array in many cases, with the same copy-on-write semantics
helping developers avoid spooky action-at-a-distance. I'm confident that by
the time that such a feature would be ready for primetime, there would be
tools in place to assist migrations. We could also presumably allow for
casts between vec and array.

And once opcache is sorted out, I'm also confident that the advice "using
vec will make your code a bit faster" would be a successful recruitment
tool.

Best wishes,

Matt

Re: [PHP-DEV] RFC: Add `final class Vector` to PHP

[Matthew Brown]

On Thu, 16 Sept 2021 at 23:33, tyson andre 
wrote:

> Yeah, as mentioned in
> https://wiki.php.net/rfc/vector#adding_a_native_type_instead_is_vec , it
> would require a massive amount of work.
>
> - A standard library for dealing with `vec`, filtering it, etc
> - Userland libraries and PECLs would need to deal with a third complex
> type different from array/object that probably couldn't be implicitly
> - Extensive familiarity with opcache and the JIT for x86 and other
> platforms beyond what I have
> - Willingness to do that with the uncertainty the final implementation
> would get 2/3 votes with backwards compatibility objections, etc.
>

I feel like the standard library could be added in userland first, and then
corresponding faster implementations could arrive in the std lib.

But the last point is a really important one, and feels like a weakness in
the RFC process.

I know RFCs without implementations are generally frowned upon, but if
2/3rds of the community agreed that they wanted some sort of vec[] support
in theory, it might then free up the implementer(s) to take a more granular
approach to supporting vec. It could, for example, be an experimental
feature for a minor version.

Best wishes,

Matt

On Thu, 16 Sept 2021 at 23:33, tyson andre 
wrote:

> Hi Levi Morrison,
>
> > I'm okay with a final Vector class in general. I don't love the
> > proposed API but don't hate it either. Feedback on that at the end.
> >
> > What I would _love_ is a `vec` type from hacklang, which is similar to
> > this but pass-by-value, copy-on-write like an array. Of course, this
> > would require engine work and I understand it isn't as simple to add.
>
> Yeah, as mentioned in
> https://wiki.php.net/rfc/vector#adding_a_native_type_instead_is_vec , it
> would require a massive amount of work.
>
> - A standard library for dealing with `vec`, filtering it, etc
> - Userland libraries and PECLs would need to deal with a third complex
> type different from array/object that probably couldn't be implicitly
> - Extensive familiarity with opcache and the JIT for x86 and other
> platforms beyond what I have
> - Willingness to do that with the uncertainty the final implementation
> would get 2/3 votes with backwards compatibility objections, etc.
>
> > Feedback on API:
> >
> > -  `indexOf` returning `false` instead of `null` when it cannot be
> > found. If we are keeping this method (which I don't like, because
> > there's no comparator), please return `null` instead of false. The
> > language has facilities for working with null like `??`, so please
> > prefer that when it isn't needed for BC (like this, this is a new
> > API).
>
> I hadn't thought about that - that seems reasonable since I don't remember
> anything else adding indexOf as a method name.
>
> > - `contains` also doesn't have a comparator.
>
> I was considering proposing `->any(callable)` and `->all(callable)`
> extensions if this passed.
> I'm not quite sure what you mean by a comparator for contains. There'd
> have to be a way to check if a raw closure is contained.
>
> > -  Similarly but less strongly, I don't like the filter callable
> > returning `mixed` -- please just make it `bool`.
>
> The filter callable is something that would be passed into the filter
> function. The return value would be checked for truthiness.
> The phpdoc in the documentation could be changed, but that wouldn't change
> the implementation.
>
> > - I don't know what `setSize(int $size)` does. What does it do if the
> > current size is less than `$size`? What about if its current size is
> > greater? I suspect this is about capacity, not size, but without docs
>  > I am just guessing.
>
> It's the same behavior as
> https://www.php.net/manual/en/splfixedarray.setsize.php . It's about
> size, not capacity.
>
> > Change the size of an array to the new size of size.
> > If size is less than the current array size, any values after the new
> size will be discarded.
> > If size is greater than the current array size, the array will be padded
> with null values.
>
> I'd planned to add phpdoc documentation and examples before starting a
> vote to document the behavior and thrown exceptions of the proposed methods.
>
> Thanks,
> Tyson
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Alias stdClass to DynamicObject?

[Matthew Brown]

> On Sep 6, 2021, at 11:29 AM, Nikita Popov  wrote:
> 

I think this would be a massive benefit to first-time PHP users one or two 
years from now.

I remember being confused by this terminology — I am sure bugs have been caused 
by people who assumed stdClass was a base class for all objects.

Best wishes,

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

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Matthew Brown]

On Thu, 26 Aug 2021 at 21:20, Sara Golemon  wrote:

> We're
> going to need to run some static analyzers on some frameworks and
> libraries.  Who's got it in them to do the research?
>
> -Sara
>

I'm not volunteering, but I forked Nikita's package analysis to add Psalm
scanning a while ago: https://github.com/muglug/popular-package-analysis

It's not trivial (downloading the requisite files takes up a lot of HDD
space) but Psalm's output can be parsed and analysed looking for
UndefinedPropertyFetch and UndefinedThisPropertyFetch issues.

Re: [PHP-DEV] [RFC] Never For Argument Types

[Matthew Brown]

Hey!

Using the "never" type to require that downstream libs specify a type does
not make intuitive sense to me, because the same is not true the other way
(covariantly) for return types.

The existence of a "never" type on an overriding method does not require
that upstream libs specify a return type — this is perfectly valid:

class A {
  public function foo() {}
}
class AChild extends A {
  public function foo():never { exit; }
}

Best wishes,

Matt

On Fri, 13 Aug 2021 at 19:27, Jordan LeDoux  wrote:

> Hey internals,
>
> I've been working on the draft for my operator overloading RFC, and in
> doing so I encountered a separate change that I would like to see.
>
> That is, the use of `never` as an argument type for interfaces. Since
> arguments in PHP are contravariant to preserve Liskov substitution, `never`
> as the bottom type should indicate that implementing classes can require
> any type combination they want. This is in fact consistent with type theory
> and set theory, and is how the bottom type is treated in several other
> languages.
>
> In this case, the bottom type would be used to indicate covariant parameter
> polymorphism while not conflicting with LSP.
>
> This would provide a sort of minimal form of generics to PHP without the
> issues that actual generics present from an implementation perspective. It
> would not, however, restrict or hinder any future RFC for generics.
>
> This is at the first draft stage, and I currently have the RFC on a github
> repo to allow for easy contribution and collaboration.
>
> Any feedback is greatly appreciated.
>
> https://github.com/JordanRL/never-argument-type
>
> Jordan
>

Re: [PHP-DEV] Request for karma to vote on RFCs

[Matthew Brown]

On Sun, 18 Jul 2021 at 14:47, Tobias Nyholm  wrote:

> There has not been many (maybe just one or two) RFCs where I wished the
> vote turned out the other way.
>

This was the reason that I did *not* think that I needed a vote, as a
prolific PHP coder — while individual voters might be voting the "wrong"
way, in the aggregate the decisions were all pretty good. While I think
it's important for me to share my opinion (because my opinion is, like, the
best opinion), I don't think that opinion needs to be able to vote.

You and I still have soft power — we can use our platform (many existing
voters follow both you and I on Twitter) to encourage people to vote yes on
an RFC we feel strongly about e.g.
https://twitter.com/psalmphp/status/1347163072587186178.

There are also lots of examples of non-voters influencing RFCs to make them
more acceptable to the wider PHP community:
https://twitter.com/brendt_gd/status/1335090303192195075

Best wishes,

Matt

Re: [PHP-DEV] [RFC] is_literal

[Matthew Brown]

I've just added support for a `literal-string` type to Psalm:
https://psalm.dev/r/9440908f39

This will remain whether or not the RFC passes, but if it passes the
is_literal check will be used to inform Psalm in a similar fashion to how
array_is_list (coming in 8.1) will inform Psalm's list array type.

Adding the literal-string type guard to our main SQL creation endpoint
identifies roughly 20% of all DB queries that would _not_ pass the
`is_literal` check, and would need to use some sort of explicitly unsafe
endpoint. From my perspective biggest issue with the current approach is
that

implode(', ', [1, 2, 3])

is treated as non-literal. We have a lot of queries that look like

WHERE `foo` IN (' . implode(', ', self::ALLOWED_IDS) . ')'

and these would all have to take the "unsafe" path, which is a bit
annoying. Could you add the same flag to ints, or is that too hard?

On Sat, 12 Jun 2021 at 13:00, Craig Francis 
wrote:

> Hi Internals,
>
> I'd like to start the discussion on the is_literal() RFC:
>
> https://wiki.php.net/rfc/is_literal
>
> is_literal() brings a proven way to identify Injection Vulnerabilities to
> PHP, already used by Google in their Java and Go projects, and is currently
> being added to JavaScript. It's a lightweight and simple approach:
> "Distinguishing strings from a trusted developer from strings that may be
> attacker controlled", allowing Libraries to identify the mistakes made by
> the thousands of developers using them incorrectly.
>
> When Libraries use is_literal() to protect against these mistakes, we can
> trust their output, and (as covered in the Future scope section) PHP can
> then raise warnings with certain native functions like PDO::query,
> mysqli_query, exec, preg_match, etc. (we would only consider warnings,
> anything stricter like exceptions would be in many years time, if at all -
> the intention is to alert and inform people, not break things).
>
> The length is due to the FAQ Section, on why it's needed, how it can be
> used by Libraries, and the important differences of using this flag versus
> the flawed Taint Checking approach with its false sense of security
> (error-prone escaping).
>
> Thanks,
> Craig Francis
>
>
> PS: If anyone wants to discuss face-to-face on Zoom, I'll be available (UK
> Time/BST/UTC+1) at:
>
> https://chat.craigfrancis.co.uk/
>
> Saturday 12th June, 6pm to 8pm;
> Sunday 13th June, 10am to Midday;
> Monday 14th June, 5pm to 7pm;
> Tuesday 15th June, 9pm to 11pm;
> Thursday 16th June, 10am to Midday;
> (other times on request)
>

Re: [PHP-DEV] [RFC] is_literal

[Matthew Brown]

On Mon, 14 Jun 2021 at 08:30, Dan Ackroyd  wrote:

> Hi Craig, Joe,
>
> While I think the idea behind this RFC is great, the current
> implementation is terrible, as it will cause some fatal errors in
> production.
>
>
I'm not sure it's productive to call the implementation terrible. With
Someniatko's suggestion of a literal-string type, that issue (like so many
others) could be caught by a type-checker:

/** @return literal-string */
function getColor(): string {
return $_GET["color"]; // this would trigger a typechecker error
}

In fact I think there's a solid case for adding support for literal-string
to type checkers like mine today — mainly to prevent patterns that might
later lead to SQL injection.

Re: [PHP-DEV] [RFC] is_literal

[Matthew Brown]

On Sat, 12 Jun 2021 at 13:00, Craig Francis 
wrote:

> Hi Internals,
>
> I'd like to start the discussion on the is_literal() RFC:
>
> https://wiki.php.net/rfc/is_literal
>
> is_literal() brings a proven way to identify Injection Vulnerabilities to
> PHP, already used by Google in their Java and Go projects, and is currently
> being added to JavaScript. It's a lightweight and simple approach:
> "Distinguishing strings from a trusted developer from strings that may be
> attacker controlled", allowing Libraries to identify the mistakes made by
> the thousands of developers using them incorrectly.
>
> When Libraries use is_literal() to protect against these mistakes, we can
> trust their output, and (as covered in the Future scope section) PHP can
> then raise warnings with certain native functions like PDO::query,
> mysqli_query, exec, preg_match, etc. (we would only consider warnings,
> anything stricter like exceptions would be in many years time, if at all -
> the intention is to alert and inform people, not break things).
>
> The length is due to the FAQ Section, on why it's needed, how it can be
> used by Libraries, and the important differences of using this flag versus
> the flawed Taint Checking approach with its false sense of security
> (error-prone escaping).
>
> Thanks,
> Craig Francis
>
>
> PS: If anyone wants to discuss face-to-face on Zoom, I'll be available (UK
> Time/BST/UTC+1) at:
>
> https://chat.craigfrancis.co.uk/
>
> Saturday 12th June, 6pm to 8pm;
> Sunday 13th June, 10am to Midday;
> Monday 14th June, 5pm to 7pm;
> Tuesday 15th June, 9pm to 11pm;
> Thursday 16th June, 10am to Midday;
> (other times on request)
>


Hi Craig and Dan,

I was skeptical about the first draft of this RFC when I saw it last
month, but now I see the light (especially with the concat changes). This
looks like a very solid solution for any library authors wanting to add a
layer of protection against SQL injection attacks. Sorry for any
unnecessary grief I caused.

The only remaining issue I have is performance — Psalm and other static
analysis tools perform quite a lot of concatenation (and never have to
worry about user input). What sorts of slowdowns do you see when running
those tools?

Best wishes,

Matt

Re: [PHP-DEV] [RFC] Readonly properties

[Matthew Brown]

This is a great idea!

Might be worth mentioning that Psalm already supports a `@readonly`
docblock annotation (first suggested by Nuno Maduro), and it matches the
proposed behaviour (though Psalm doesn't currently prevent inheritance
issues):

Example: https://psalm.dev/r/7ed5872738

On Fri, 4 Jun 2021 at 11:19, Nikita Popov  wrote:

> Hi internals,
>
> I'd like to open the discussion on readonly properties:
> https://wiki.php.net/rfc/readonly_properties_v2
>
> This proposal is similar to the
> https://wiki.php.net/rfc/write_once_properties RFC that has been declined
> previously. One significant difference is that the new RFC limits the scope
> of initializing assignments. I think a key mistake of the previous RFC was
> the confusing "write-once" framing, which is both technically correct and
> quite irrelevant.
>
> Please see the rationale section (
> https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
> proposal relates to other RFCs and alternatives.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] [RFC] First-class callable syntax

[Matthew Brown]

On Thu, 20 May 2021 at 10:17, Ondřej Mirtes  wrote:

> Hi, I’m confused by the syntax, when I read it, I think to myself “I know
> this, this is just a method call… oh wait, it’s actually a callable”. It
> really makes my head hurt.
>

I agree with the first point — slightly confusing initially, but I can see
myself get used to it. I suggested strlen(=>) as an alternative, not sure
if that would cause parsing difficulties.


> Also, static analysers already have to reason about current code, so
> PHPStan (and Psalm probably too) already supports referencing to callables
> as strings (global functions) and arrays (methods):
>
> $name = 'date';
> $name(1); // Parameter #1 $format of callable 'date' expects string, int
> given.
>

I disagree here: while Psalm can understand what's going on in the above
code, callables are definitely (in my opinion) the most hairy part of PHP's
type system.

The RFC gives an example of something not caught by either PHPStan or Psalm:

https://psalm.dev/r/21217fdfb4
https://phpstan.org/r/6cc8cdc2-ecc6-403d-887d-0f12f4813b75

Discouraging this particular formulation would make affected codebases safe
from this particular error.

Best wishes,

Matt

Re: [PHP-DEV] [RFC] Property accessors

[Matthew Brown]

On Tue, 4 May 2021 at 06:34, Nikita Popov  wrote:

> Hi internals,
>
> I'd like to present an RFC for property accessors:
> https://wiki.php.net/rfc/property_accessors
>
> Property accessors are like __get() and __set(), but for a single property.
> They also support read-only properties and properties with asymmetric
> visibility (public read, private write) as a side-effect.
>
> The proposal is modeled after C#-style accessors (also used by Swift), and
> syntactically similar to the previous
> https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 proposal.
>
> While I put a lot of effort into both the proposal and the implementation,
> I've grown increasingly uncertain that this is the right direction for us
> to take. The proposal turned out to be significantly more complex than I
> originally anticipated (despite reducing the scope to only "get" and "set"
> accessors), and I'm sure there are some interactions I still haven't
> accounted for. I'm not convinced the value justifies the complexity.
>
> So, while I'm putting this up for discussion, it may be that I will not
> pursue landing it. I think a lot of the practical value of this accessors
> proposal would be captured by support for read-only (and/or private-write)
> properties. This has been discussed (and declined) in the past, but
> probably should be revisited.
>
> Regards,
> Nikita
>

I don't have a vote, but I've worked on a few ActiveRecord-style ORMs in
PHP, and this is the sort of feature that would make me want to rewrite
everything to take advantage of it.

I've used property accessors in C# and really appreciated them. The 20%
increase in performance over magic getters and setters is a nice bonus.

Allowing the creation of engine-enforced private-set properties is another
bonus, even though I'm already able to enforce that in my projects via
static analysis.

Best wishes,

Matt

Re: [PHP-DEV] Method overload support

[Matthew Brown]

On Sun, 25 Apr 2021 at 16:12, David Rodrigues 
wrote:

> I know that this discussion comes back from time to time, but now that PHP
> is quite strong in relation to argument typing, I think it is worthwhile to
> have a quick discussion about it. Maybe to PHP 9.
>
> One of the things I remember that was a big problem was the performance
> impact in determining what the ideal method would be, without testing it
> each time.
>
> 1. The test only needs to happen for overloaded methods. So, most of the
> time, no change will occur.
>
> 2. Opcache may be able to help indicate which method will be executed, when
> it is available. And perhaps, in some situations, it is possible to
> determine which method will be tested as a priority, without having to test
> all the time (in a loop, for example).
>
> function printId(User $user) { return a($user->id); }
> function printId(int $userId) { printf($userId); }
>
> foreach ([1, 2, 3, 4, $userInstance] as $userId) {
> printId($userId);
> // First time:
> // 1. Overload detected, but the best option is unknown;
> // 2. Test option #1: rejected;
> // 3. Test option #2: accepted and used;
> // Next times:
> // 1. Overload detected, the last occurrence was option #2, accepted
> and used;
> // 2. Option #2 can't be used for $userInstance, retest all options
> (except #2).
> }
>
> 3. Poorly typed functions or methods cannot be overloaded.
>
> function printId(User $user) { ... }
> function printId($user) { ... } // Fatal error
>
>
> Atenciosamente,
> David Rodrigues
>

This was brought up four years ago (https://externals.io/message/93831) and
you brought this up two years ago, but I don't think anything has changed
to change the answer.

The responses in the four-years-ago post contain some good explanations.
Unless you have a draft implementation that fixes the issues mentioned I'm
not sure it's productive to bring it up again.

Best wishes,

Matt

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Matthew Brown]

> On Apr 24, 2021, at 10:43 AM, Levi Morrison via internals 
>  wrote:
> 
> On Sat, Apr 24, 2021 at 8:04 AM Benjamin Eberlei  wrote:
>> 
>>> On Sat, Apr 24, 2021 at 2:56 PM Pierre  wrote:
>>> 
>>> Le 24/04/2021 à 12:55, Saif Eddin Gmati a écrit :
 Hello Internals,
 
 I'm sending this email to open discussion about sealed classes,
 interfaces, and traits feature for PHP 8.1.
 
 I have create a Draft RFC here:
 https://wiki.php.net/rfc/sealed_classes
 
 
 A major concern for few people have been the syntax, in which it
 introduces 2 new keywords into the languages, therefor, i have added a
 section about alternative syntax which could be used to avoid this
 problem.
 
 Regards,
 
 Saif.
>>> 
>>> Hello,
>>> 
>>> And why not using an attribute, such as in HackLang ?
>>> 
>> 
>> +1 on this, I said the same on the "never/noreturn" RFC. There is a much
>> less invasive way to add new keywords/flags to functions by using
>> attributes.
>> 
>> Imho this decouples new features from the language and reduces the "risk"
>> of adding them to the language. That should increase the likeliness of it
>> getting accepted in my opinion.
> 
> I think an attribute may be appropriate here because sealed types act
> like normal types, except we restrict who can extend them.
> Additionally, we have to provide data about which types can extend the
> sealed type, so it's not just a simple on/off type behavioral switch
> (which I think is an antipattern for attributes based on my experience
> in other languages that have them).
> 
> This is different from a return type `never`. A function which never
> returns cannot meaningfully have any return type at all -- using
> `void` or some other type with an attribute would be a lie.
> Additionally, there isn't any meta-data to associate with the `never`.
> I hope this comment doesn't digress into a conversation about `never`;
> that isn't my point. I'm trying to provide more justification about
> when I think attributes are appropriate, because I think they may be
> appropriate here and I think it's useful to show how `never` is
> different.
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Yeah I second this — I think an attribute might be more appropriate here, and I 
obviously didn’t feel that way about the “never” RFC.

One big benefit of a keyword over an equivalent attribute is that when you see 
`#[Sealed(...)]` you have to check use statements above to ensure it refers to 
the actual ‘Sealed’ attribute.

What if PHP reserved double-underscore-prefixed attributes for engine use (and 
treated them as fully-qualified)? Hack does this currently, so you always know 
what a `<<__Sealed(Foo::class, Bar::class)>>` attribute will do, regardless of 
use statements.

Best wishes,

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

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

[Matthew Brown]

Hey!

The vote is now closed (a little tardily, I’m on holiday).

Yays: 42
Nays: 11

The Yays have it.

There was an additional vote on noreturn vs never:

noreturn: 14
never: 34

Never is the clear winner, so we’ll adopt never for the name of PHP’s bottom 
type.

Thanks to everyone who contributed comments and suggestions!

Matt and Ondřej 

> On Mar 30, 2021, at 11:06 AM, Matthew Brown  wrote:
> 
> 
> Hey everyone!
> 
> The vote for adding noreturn is now open:
> 
> https://wiki.php.net/rfc/noreturn_type
> 
> Voting will run through April 13th
> 
> Best wishes,
> 
> Matt and Ondrej

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

[Matthew Brown]

On Sat, 3 Apr 2021 at 22:29, David Rodrigues  wrote:

> It is very likely that the proposal will be accepted (it is already 33/10),
>

I'm definitely not counting my chickens.


> Is there any chance of discussing terms, even if the "never" indication is
> winning at the moment? Or did I miss this discussion?
>

The RFC discussion is here: https://externals.io/message/113442. Someone
suggested "terminus", but nobody replied supporting that suggestion (that
was your opportunity!). Lots of people suggested "never", enough that a
vote on "noreturn" vs "never" was added to the final RFC.

As for "terminus", I don't think there's much benefit to PHP having its own
separate term for a type "noreturn"/"never" that already exists in other
languages. I know that naming is one of the "two hard things", but there's
no need to make it any harder.

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

[Matthew Brown]

On Sat, 3 Apr 2021 at 12:30, Benjamin Eberlei  wrote:

>
> But adding a new keyword "noreturn" would not be necessary, it could just
> be an Attribute as i said in my first e-mail explaining my no-vote:
>
> #[NoReturn] // sets a function flag modifying the void behavior
> public function foo(): nothing {
> return; // throws if it reaches this point
> }
>
> This would be closer to what Psalm and PHP-Stan use at the moment if we
> replace nothing with void.
>
> The problem is that "void" is already not perfect, since the callside
> doesn't care about "return null" with no return type vs "return" + void
> return type.
>
> If we had "nothing" and "null" instead of "void", and we'd say like PHP
> works, "return;" actually means "return null;", then:
>
> function foo(): nothing {
> return; // Error: cannot return null from a function that returns
> nothing.
> }
> function bar(): null {
> return;
> // or return null;
> }
>
> This would more consistently tie into union types where |null is allowed,
> however on its own it is not: "foo() : null => error".
>
> As Levi said, this noreturn/never just perpetuates/amplifies the existing
> void mistake and feels off, given that other recent changes to PHP have
> been more bold, towards removing inconsistencies.
>
>
Clearly comparisons of "noreturn"/"never" to "void" are a bit of a
minefield, because a number of contributors feel that void was a mistake,
that its implementation doesn't feel PHP-like.

While I disagree that our proposal is intrinsically connected with the void
one – noreturn/never could work equally well with a "null" return — our
proposal does perpetuate one idea behind "void": that PHP can benefit from
types found in other languages and type systems, and especially types found
in Hack.

It seems like some of the debate is over whether "noreturn"/"never" is a
behaviour or a type. If it were purely a behaviour, with no meaning as a
type, an Attribute would be a much more appropriate location.

It's not just a behaviour, though — it is a type that follows variance
rules, and it's a type that PHP can check.

If "void" returns are too much of a distraction, think instead of "object"
return type declarations:

When executing the function

function returnsObject($o) : object {
if (rand(0, 1)) {
return $o;
}
}

Here PHP's engine checks two separate behaviours

1. when the function explicitly returns, does it return an object?
2. does the function ever finish without returning or throwing or exiting?

Only the first actually involves a strict type check. The second is a
generic behaviour check, triggered by the existence of a return type. This
is essentially the same check that we want to trigger with
"noreturn"/"never".

In fact, as someone recently pointed out, running the following code
*today* produces similar errors to the ones we propose:

function php7Redirect() : noreturn {
if (rand(0, 1)) {
return "bad"; //  Fatal error: Uncaught TypeError
}
header("Location: https://php.net;);
exit; // OK
}

Our RFC makes this code explicitly legal, and adds covariance. Indeed our
implementation is small because it correctly treats "noreturn"/"never" as a
type, allowing us to use the existing return type handling.

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

[Matthew Brown]

On Tue, 30 Mar 2021 at 13:51, Ilija Tovilo  wrote:

> Hi Matthew
>
> > I like the proposal. I also support the covariance.
> >
> > One question though.
> > The RFC mentions possible future use of "nothing" as a bottom type for
> > parameters in generics. This makes a lot of sense to me. Even without
> > generics, it could be used for parameters in abstract methods.
> >
> > So why not already introduce "nothing" as the universal bottom type, and
> > use it instead of "noreturn"?
> > Can "noreturn" do anything that "nothing" can't?
>
> I'm also a little confused by this statement. The exact wording from the
> RFC is:
>
> > Arguments for never: ... It's a full-fledged type, rather than a keyword
> used in a specific situation. A far-in-the-future generics proposal could
> use never as a placeholder inside contravariant generic types.
>
> From what I understand, in Hack noreturn and never are both
> full-fledged types. Nothing is a bottom type while noreturn is not.
> Since in your proposal noreturn would also be a bottom type there's no
> reason why it couldn't be used in covariant or contravariant generic
> parameters.
>
> Please correct me if I'm missing something.
>
> Ilija
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
In Hack it's a bit confusing. I think the Hack team ultimately decided that
"nothing" was a better name for the bottom type than "noreturn", and
confusingly introduced one while the other was still active.

They have a long-term plan to deprecate "noreturn" in favour of "nothing"
and stop supporting the former name, though it's unclear when that might
happen.

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

[Matthew Brown]

On Thu, 1 Apr 2021 at 04:56, Benjamin Eberlei  wrote:

> This RFC is using the declaration of the return type, to specify that it
> never returns. As such noreturn or never is a keyword a long the lines of
> public or final, but it is not a return type.
>
> I don't think the argument for potential optimizations in Opcache to
> eliminate dead code or allow IDEs to hint at dead code are valuable enough
> to justify this change.
>

By this argument "void" should also be an attribute – there's no reason to
hint a value that's not being returned.

You'd write functions like

[\Void]
function foo() { ... }

But we don't do that, because the wider programming language community has
agreed that "void" is a type, and at compile-time PHP's engine can ensure
that "void" functions do not return a value.

"Noreturn"/"never" is also recognised as a type by the wider programming
language community. It can be checked at both compile-time and run-time by
the engine, as detailed in the RFC. Indeed, _no other return type makes
sense in the context_.

The type definitely felt awkward when I first started using it in
docblocks, but after a while it started to make intuitive sense.

Best wishes,

Matt/Ondrej

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

[Matthew Brown]

On Wed, 31 Mar 2021 at 09:30, Theodore Brown  wrote:

> On Tue, Mar 30, 2021 at 5:24 PM Matthew Brown 
> wrote:
>
> > On Tue, 30 Mar 2021 at 12:55, Theodore Brown 
> wrote:
> >
> > > On Tue, Mar 30, 2021 at 10:06 AM Matthew Brown <
> matthewmatt...@gmail.com> wrote:
> > >
> > > > Hey everyone!
> > > >
> > > > The vote for adding noreturn is now open:
> > > >
> > > > https://wiki.php.net/rfc/noreturn_type
> > > >
> > > > Voting will run through April 13th
> > >
> > > Hi Matt and Ondrej,
> > >
> > > Thanks for your work on this RFC. I voted for `never` as the type name
> > > because it's more amenable to future use cases like compile-time
> > > exhaustiveness checks (example:
> > >
> https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-never-type
> ).
> > >
> > > As a bonus `never` is more concise, avoids mashing two words together,
> > > and aligns with TypeScript, which I and many other PHP devs also use.
> >
> > Awesome! The conciseness argument for "never" is already mentioned in
> > the RFC, as is TypeScript's use of the term.
> >
> > Full disclosure (because neither of us is eligible to vote):
> > I slightly prefer "noreturn", and Ondrej strongly prefers "never".
>
> Hi Matt,
>
> I'm confused by this. If Ondrej strongly prefers `never`, why does the
> RFC say "we believe `noreturn` is the best name for this type"?
>
> It might be better to just remove this sentence, or else list your
> separate preferences.
>
> Thanks,
> Theodore


I've removed that sentence.

Opinions evolved — I wrote the RFC with the original language favouring
"noreturn", Ondrej edited it, adding more arguments for "never". Since we
published the RFC some in the community have validated his arguments, and I
think Ondrej's opinion has become stronger as a result (and mine has become
weaker). Whatever happens, I think we care much more that this passes than
what it's exactly called.

Best wishes,

Matt

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

[Matthew Brown]

On Tue, 30 Mar 2021 at 12:55, Theodore Brown  wrote:

> On Tue, Mar 30, 2021 at 10:06 AM Matthew Brown 
> wrote:
>
> > Hey everyone!
> >
> > The vote for adding noreturn is now open:
> >
> > https://wiki.php.net/rfc/noreturn_type
> >
> > Voting will run through April 13th
>
> Hi Matt and Ondrej,
>
> Thanks for your work on this RFC. I voted for `never` as the type name
> because it's more amenable to future use cases like compile-time
> exhaustiveness checks (example:
>
> https://www.typescriptlang.org/docs/handbook/2/narrowing.html#the-never-type
> ).
>
> As a bonus `never` is more concise, avoids mashing two words together,
> and aligns with TypeScript, which I and many other PHP devs also use.
>
> Kind regards,
> Theodore


Awesome! The conciseness argument for "never" is already mentioned in the
RFC, as is TypeScript's use of the term.

Full disclosure (because neither of us is eligible to vote):
I slightly prefer "noreturn", and Ondrej strongly prefers "never".

[PHP-DEV] [VOTE] noreturn type

[Matthew Brown]

Hey everyone!

The vote for adding noreturn is now open:

https://wiki.php.net/rfc/noreturn_type

Voting will run through April 13th

Best wishes,

Matt and Ondrej

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

[Matthew Brown]

> On Mar 29, 2021, at 1:25 PM, Ilija Tovilo  wrote:
> 
> Hi Matthew
> 
>> Ondřej Mirtes and I present an RFC for the noreturn type:
>> https://wiki.php.net/rfc/noreturn_type
>> 
>> The feature already exists in Hack (the primary inspiration) and is
>> currently supported by our static analysis tools inside docblocks, and we
>> feel there's a good argument for it to be supported by PHP itself.
> 
> Thanks for the RFC! I'm very much in support of it.
> 
> Two small things:
> 
> 1. Some magic methods like __toString currently require a specific
> return type (like string in that case). Since noreturn is a bottom
> type technically it should be possible to type hint those magic
> methods with noreturn. It's not a big issue if that's not possible,
> but it should be mentioned in the RFC.
> 
> 2. noreturn is one of the few return types that would technically make
> sense for __construct (other than void).
> 
> class Foo {
>public function __construct(): noreturn {
>throw new Exception();
>}
> }
> 
> new Foo();
> bar(); // < Dead code
> 
> Not sure this is worth supporting but I just wanted to mention it.
> 
> Ilija
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Thanks, I’ll update the RFC to mention __toString, but I’ll steer clear of 
__construct
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Matthew Brown]

If there are no more questions, we plan to open up voting for this on Tuesday 
March 30. There will be two votes — a 2/3 majority required for the feature, 
and a simple majority required for the name — “noreturn” vs “never”.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

[Matthew Brown]

On Thu, 25 Mar 2021 at 12:24, Nuno Maduro  wrote:

> Hi,
>
> Concerning the comments about what's exactly "auto-captured" by the scope
> of a multi-line short closure, we will be just reusing the "auto-capture"
> feature that already exists in one-line short closures. Therefore, this RFC
> doesn't have plans on changing the way "auto-capture" already works in PHP.
>

Absolutely, but allowing assignments in short closures increases their
complexity, and thus (in my opinion) erases the advantage of auto-capturing.

I know you can _also_ have assignments in short closures (because
assignments are just expressions in PHP), but it's much harder to come up
with short closure gotchas.

Re: [PHP-DEV] [RFC] Auto-capture multi-line closures andshortfunctions take 2

[Matthew Brown]

On Thu, 25 Mar 2021 at 10:23, Christian Schneider 
wrote:

> Am 25.03.2021 um 14:29 schrieb Mark Randall :
> > On 25/03/2021 09:28, Rowan Tommins wrote:
> >> That's not quite what I meant. I meant that you can't say "capture by
> default, but this variable is definitely local".
> >
> > I think if there's one argument against, this would be it, but IMHO it
> is a weakness in PHP as a whole.
>
> I'm not sure if I misunderstand what you're saying but to me it is one of
> the greatest things about PHP that everything is local by default (minus a
> narrow set of well-known and easily enough recognizable things).
>
> > The solution would be adding JS-like let / const statements. Which would
> be a benefit to other things too.
>
>
> I disagree that this is the solution. I think JS had to add var and later
> let because of the unfortunate decision to have C-like scoping rules.
> Making scoping in PHP more complex to be able to repeat this mistake in
> some form seems ill-advised to me.
>
> - Chris
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
This is also my feeling. While it's easy to see from the single line

fn ($x, $y)  => $x + $y + $z

that $z is auto-captured, it's much less easy to see that in

fn ($x, $y) {
$x += $y >> 2;
$y = 2 - $y;
$z -= 4;
return $x + $y + $z;
}

Here's an example of this auto-catpuring multi-line functions in use today:
https://github.com/hhvm/hhast/blob/bb0f0445b2e693270079dcced01a29919d87e955/src/Migrations/IsRefinementMigration.hack#L54-L111
I think that code would be more a little more readable with an explicit
closure
function($node, $parents) use ($map) {

Lastly, PHP's handling of arrays adds an auto-capturing gotcha:

   fn ($x, $y) {
$z[] = 1;
return $x + $y + count($z);
}

This is valid whether or not $z is defined before the closure.

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

[Matthew Brown]

On Tue, 23 Mar 2021 at 05:32, G. P. B.  wrote:

> I'm calling this proposal pure intersection types as there would be no
> possibility of mixing intersection and union types, I'm leaving this as a
> future scope.
>

Does this miss an opportunity, though? It's useful to be able to write
A|null.

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

[Matthew Brown]

On Sat, 20 Mar 2021 at 11:35, Larry Garfield  wrote:

> My main concern is around the covariance of inheritance.  The example
> given:
>
> abstract class Person
> {
> abstract public function hasAgreedToTerms(): bool;
> }
>
> class Kid extends Person
> {
> public function hasAgreedToTerms(): noreturn
> {
> throw new \Exception('Kids cannot legally agree to terms');
> }
> }
>
> While that may be technically correct from a type theory perspective (my
> type theory isn't strong enough to say either way), I don't feel like that
> obeys Liskov.


It absolutely obeys Liskov, because noreturn is the subtype of all
subtypes, aka the bottom type.


> If I have an array of Person objects, and I iterate them to check if
> they've all agreed to terms, I expect the return value to be a *usable*
> type in the Person interface or a subtype of it *that I can still use*.  I
> cannot use Kid::hasAgreedToTerms's return type, because it's by definition
> non-existent.


Luckily your program will never have the chance to use its return type,
because calling the method throws an exception.


> That feels like a bad time bomb.
>

You might, in this scenario, add a `@throws` docblock and hope some sort of
static analysis rule might catch the time bomb

Another way that you can think of this is with throw expressions. The
ternary in the function below is supposed to return `string`, or a subtype
of `string` (the literal string "hello" is a subtype of `string`). The
types are valid here if the type of `throw new Exception...` is treated as
`noreturn`, and if `noreturn` is a subtype of `string`.

```
 Other than that concern, I'm fine with the spec.  I would marginally
> prefer "never" over "noreturn", but not enough to vote against it just for
> that.
>

There will be a separate vote for noreturn vs never!


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

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

[Matthew Brown]

On Fri, 19 Mar 2021 at 10:53, Nikita Popov  wrote:

> On Fri, Mar 19, 2021 at 3:45 PM Marco Pivetta  wrote:
>
>> Hey Nikita,
>>
>> On Fri, Mar 19, 2021, 14:35 Nikita Popov  wrote:
>>
>>>
>>> Is it allowed to declare a noreturn function that returns by reference?
>>>
>>> function (): noreturn {}
>>>
>>
>> Given that `noreturn` means it should throw, loop forever or exit, how
>> would a by-ref usage be applied/useful?
>>
>> Or is it a hint at a missing test?
>>
>
> Mainly a hint for missing spec ;)
>
> Context is that we're considering to deprecate by-ref void return (
> https://wiki.php.net/rfc/deprecations_php_8_1#return_by_reference_with_void_type),
> so it would make sense to me to prohibit this for noreturn from the start.
>
> However, I could also see an argument for why allowing it may be useful
> due to variance considerations. It would allow you to write something like
> this:
>
>  class A {
> public function (): int { ... }
> }
> class B extends A {
> public function (): noreturn { throw new Exception; }
> }
>
> While dropping the by-ref return on B::test() would be forbidden by
> variance (and I don't think we'd want to add more special rules here, like
> ignoring ref-return variance for noreturn functions).
>
> Regards,
> Nikita
>

I think it should be allowed due to the variance considerations – I've
updated the RFC to include your example.

Re: [PHP-DEV] [RFC Proposal] Allow methods to 'become' static

[Matthew Brown]

On Mon, 15 Mar 2021 at 09:36, Nikita Popov  wrote:

> I'm not sure I follow your point. The fact that something is compatible,
> does not mean that you can just blindly perform a forwarding call. For
> example, consider this:
>
> class A {
> public function method(string $x) {}
> }
>
> class B extends A {
> public function method(string|int $x) {
> parent::method($x);
> }
> }
>
> B::method() is compatible with A::method() from a typesystem perspective.
> But that doesn't mean that a parent::method() call will work. The above
> code is simply an implementation bug in B::method(), but doesn't say
> anything fundamental about the compatibility of the signatures. I would
> argue that the same holds in your example.
>
> Disclaimer: I have some serious doubts that allowing non-static->static
> changes is worthwhile, I just don't see why it would be outright unsound.
>
> Regards,
> Nikita
>

Ah OK! When I say "unsound" I mean "the type system implied by PHP's
behaviour allows code that a static analysis tool cannot catch".

It's trivial for a static analysis tool to find a bug in your example:
https://psalm.dev/r/3cd498b539

If PHP changed to allow child methods of instance methods to become static,
static analysis tools could follow suit, but that would invite undetectable
unsound behaviour.

The most well-known example of PHP's existing unsoundness is its treatment
of array keys, something that static analysis tools cannot detect:
https://psalm.dev/r/4640ef8f22 vs https://3v4l.org/XQTWc

Re: [PHP-DEV] [RFC Proposal] Allow methods to 'become' static

[Matthew Brown]

On Sun, 14 Mar 2021 at 18:09, Rowan Tommins  wrote:

> Are you saying that having the parent::getSomeInt() call fail would be
> problematic?
>
>
 Yes, that's where this becomes unsound – you can call the child method
statically, but the parent call assumes a dynamic instance.

This is just my perspective (as someone building a tool that helps prevent
people from shooting themselves in the foot), but PHP should not allow
_more_ unsound behaviour than it already does.

Best wishes,

Matt

Re: [PHP-DEV] [RFC Proposal] Allow methods to 'become' static

[Matthew Brown]

On Sun, 14 Mar 2021 at 12:02, Gert de Pagter  wrote:

> Hey Internals,
>
> Recently i've been working on an older code base, where we have a lot
> of classes with all
> static methods. We've been moving to injecting the classes, and
> calling the methods as if they
> were not static.
>
> I wanted to add interfaces to these classes, with non static methods,
> so we can pretend in our implementation they are not static, and allow
> us to easier switch to non static methods in the future.
>
> This is (currently) not allowed by the language: https://3v4l.org/WKdvM
> Is there any chance of this being possible in future versions of PHP?
> This would only allow 'normal' methods to become static. Making static
> methods non static would break Liskov substitution principle in PHP as
> you may not be able to call the method in the same way. This means you
> can't have a 'normal' method become static in an inherited class, and
> then become 'normal' again in another inherited class. This works the
> same way with co/contra-variance in return/parameter types:
> (https://3v4l.org/j1SO9)
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
It's maybe possible in the special case of implementing interfaces, but
it's unsound for general inheritance:

someInt;
}
}

class B extends A {
public static function getSomeInt() : int {
return parent::getSomeInt();
}
}

https://3v4l.org/WnaES

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

[Matthew Brown]

On Wed, 10 Mar 2021 at 16:04, Kamil Tekiela  wrote:

> I am concerned with some edge cases. What if a function both returns and
> throws at the same time? For example:
>
> function a():noreturn {
> return throw new Exception('Boom!');
> }
>
> or
>
> function a():noreturn {
> try {
> throw new Exception('Boom!');
> } finally {
> return;
> }
> }
>

In both cases those are compile-time errors, since no return is allowed in
a function that has the noreturn type.

I've added both as tests (
https://github.com/php/php-src/pull/6761/commits/56ae52e84da5c063c28ba7739ac15979e61afc91)
but I don't _think_ it's necessary to mention it in the PR given how much
of an edge-case it is.


> Also, the message "TypeError: a(): Nothing was expected to be returned" is
> inaccurate. It should say that the function should terminate instead of
> returning. It's also not a TypeError if no value is expected. At the moment
> it sounds like we need to make the function somehow return nothing.
>

It's a TypeError because noreturn is a type, but I agree the error message
could be improved.

Ilija suggested "noreturn function was expected to throw, terminate or run
infinitely" and I'd welcome other suggestions.


> If we are to bikeshed about the name then we might also consider other
> possibilities: None, Nothing, Returnless
>

I'd prefer to stick to noreturn and never, which have plenty of precedent
in other languages' type systems.

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

[Matthew Brown]

On Wed, 10 Mar 2021 at 13:55, Rowan Tommins  wrote:

> I am however slightly confused by what exactly the implementation
> checks, and when. Is it actually looking for "exit" and "throw" statements?
>

No. Any function annotated with `: noreturn` causes the engine to insert
a ZEND_VERIFY_NORETURN_TYPE op at the end of the function's operands.

If the Zend engine hits that operand — which only happens if a throw/exit
*hasn't* been encountered — it emits a TypeError.

The other thing I'd like to mention is that PHP's implementation of
> "void" consists mostly of checking that there is no return statement, so
> a separate keyword of "noreturn" may well cause confusion. I would
> personally prefer the name "never" for this reason.
>

If a significant number agree I can add a secondary vote on noreturn vs
never, but never introduces more of a BC risk.

Best wishes,

Matt

[PHP-DEV] [RFC] noreturn type

[Matthew Brown]

Hey,

Ondřej Mirtes and I present an RFC for the noreturn type:
https://wiki.php.net/rfc/noreturn_type

The feature already exists in Hack (the primary inspiration) and is
currently supported by our static analysis tools inside docblocks, and we
feel there's a good argument for it to be supported by PHP itself.

Thanks,

Matt & Ondřej

[PHP-DEV] Re: Karma request for mattbrown

[Matthew Brown]

Thanks!

On Wed, 10 Mar 2021 at 11:30, Christoph M. Becker  wrote:

> On 10.03.2021 at 16:54, Matthew Brown wrote:
>
> > Long-time internals lurker, first-time RFC creator & C coder.> > Could I
> get some karma please?
> Sure!  RFC karma has been granted for mattbrown.  Best of luck with the
> RFC!
>
> --
> Christoph M. Becker
>
>

[PHP-DEV] Karma request for mattbrown

[Matthew Brown]

Hey!

Long-time internals lurker, first-time RFC creator & C coder.

Could I get some karma please?

Best wishes,

Matt

Re: [PHP-DEV] Avoiding enum reserved keyword

[Matthew Brown]

On Tue, 23 Feb 2021 at 06:21, Nikita Popov  wrote:

> Another possibility would be to recognize T_ENUM in the lexer, but only if
> it is followed by whitespace and an identifier. This would possibly be
> friendlier for tooling using token_get_all(). It would not permit comments
> in between the tokens though.
>

 I like this option. I can't think anyone would want to write "enum /**
some comment */ Foo {...}"

Re: [PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)

[Matthew Brown]

Thanks, now I realise I was probably wrong to bring this up.

I had it in my mind that "::" could never appear chained together (thinking
of constants), but it's just that I've never seen code that chains them
together – i.e. this is valid:

A::b()::c()::$d::$e = 5;


On Mon, 15 Feb 2021 at 15:06, Rowan Tommins  wrote:

> On 15/02/2021 14:52, Matthew Brown wrote:
> > The most comparable example is between namespace separators:
> >
> > Ns \ bar();
> > Ns \ SOME_CONST;
> >
> > are both syntax errors.
>
>
> As Sara says, this only became an error in 8.0, and there was a rather
> specific reason for it, but I think there is a philosophical difference,
> too.
>
> "\" is part of a single piece of syntax: a fully-qualified class,
> constant, or function name. You can't write $foo\Bar or Foo\$bar or
> $foo\$bar.
>
> "::" on the other hand is an operator that can be used in a variety of
> ways. You can write $foo::bar(), Foo::$bar, $foo::$bar, {$foo .
> 'Handler'}::handle(), parent::foo(), and so on. It stands to reason that
> it would have the same whitespace rules as any other operator.
>
>
> > I was surprised to learn that PHP treats :: similar to ->
>
> I think it would be rather surprising if it *didn't* treat the two
> operators similarly, since they're so closely related.
>
>
> > I wonder if there's a benefit to removing a small potential footgun from
> > the language?
>
>
> I'm not really sure what the footgun here is. Adding newlines around
> just about any operator you can think of will lead to code that confuses
> at first glance:
>
> $x = [
>  1,
>  2,
>  3,
>  4,
>  5
> ]
>
> // Wait, we're not done yet...
>
> [2];
>
>
> Short of changing the entire language from semicolon-delimited to
> newline-delimited, that's inevitable.
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)

[Matthew Brown]

On Mon, 15 Feb 2021 at 11:05, Sara Golemon  wrote:

> That change was made very recently (8.0) and was done for technical
> reasons (attributes) not aesthetic ones.
>
> Personally, I agree that adding whitespace around double colon is a
> suspect move, but breaking valid code for the sake of one's own sense of
> aesthetic doesn't progress the language, it regresses it.
>
> -Sara
>
> TL;DR - I vote No to such a change
>

OK, I take your point.

While I'm at it, I would also be happy for PHP to treat this as a parse
error (vs a runtime error, as it does currently):

$a->
list($a, $b) = $c;

But requiring zero whitespace after `->` would invalidate quite a bit of
existing code.

My reasons aren't _just_ aesthetic, mind – this also leads to ambiguity
during autocompletion in IDEs. I realise it's not internals' job to make
that easier, though.

Re: [PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)

[Matthew Brown]

There are plenty of places where PHP doesn't allow whitespace currently.

The most comparable example is between namespace separators:

Ns \ bar();
Ns \ SOME_CONST;

are both syntax errors.

`MyClass::bar()` and `MyClass::SOME_CONST` are often used in place of
`Ns\bar()` and `Ns\SOME_CONST` because the former invokes the autoloader in
a way the latter does not. My gut tells me they should behave the same way
with respect to whitespace, too.

In some situations PHP _does_ treat the identifier "Foo::bar" differently
to "Foo :: bar":

class A {
public static function b() {
return 5;
}
}

echo "A::b"(); // works
echo "A :: b"(); // fatal error

[PHP-DEV] Whitespace around Paamayim Nekudotayim (double colon)

[Matthew Brown]

Hey all,

Is there interest in prohibiting whitespace around double colons in the
next major PHP version?

I was surprised to learn that PHP treats :: similar to ->, allowing double
colons like

A::
b();

Looking at the top 2,000 packages in Packagist I can't find any evidence of
people using a double colon with whitespace around, and my suspicion is
that the use of it is basically non-existent.

I wonder if there's a benefit to removing a small potential footgun from
the language? I can't really see any benefit to _keeping_ it (unless it
turns out my analysis is wrong, and it's actually wildly popular).

Best wishes,

Matt

Re: [PHP-DEV] [RFC] Allow object keys in arrays

[Matthew Brown]

This proposal is interesting, and I see why the enum proposal makes it
useful.

Supporting this will mean a small amount of work for me (assuming it
passes) and other static analysis tools, but I don't want that to factor
into anyone's decision.

I am curious, though, whether the scope of this RFC could be narrowed to
just allowing enum cases as keys? That might avoid issues with objects that
cannot be cast to string.

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

[Matthew Brown]

>
> > or https://psalm.dev/ (open source) are projects in that area
> > (Matthew Brown is one of the authors of Psalm)
> >
> I don't like the idea of executing that on www.php.net for a few reasons,
> but someone else mentioned the possibility of donated cpu time from
> somewhere that's worth a conversation.
>
> > - A WebAssembly solution, e.g. https://phan.github.io/demo/
> >  (forked from https://oraoto.github.io/pib/) (I'm one of the maintainers
> of Phan)
> >
> Honestly, I like this solution best.  There are drawbacks, and we'd
> probably need to suppress it in certain reference chapters (e.g. mysql,
> since there's no DB to talk to), but damn if it don't feel skippy trying it
> out just now. (On my admittedly well connected, beefy dev workstation)
>
> -Sara
>

I don't think Tyson was suggesting running Psalm on php.net, merely showing
it as an example of a server-based approach. Ironically I added that
server-based demo because I was so taken by the client-side one on
hacklang.org which ran a version of Hack's typechecker transpiled from the
original Ocaml (it sadly doesn't work any more).

I think the WASM solution would be great. The 2MB download would be cached
between pages, and a simple bit of JS would ensure it was only downloaded
when a user wanted an interactive mode, and only on browsers that could run
WASM.

There'd also be the novelty of a mature language ecosystem relying on a
new, hip, technology. All the kids would love it.

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

[Matthew Brown]

W/r/t the goals:

– Promote the release of PHP 8 to the PHP developers
> – Promote PHP as a modern language, as well as the PHP 8 release, to the
> general tech audience


The page's design does a *great* job of promoting PHP 8 to existing PHP
developers, but a general tech audience skeptical of PHP's modern-day
relevance is unlikely to be swayed by improvements to WordPress
performance. I'm not sure that PHP's reputation with non-PHP developers can
be improved by a splash page.

As far as php.net can help with PHP's reputation, I think a brief homepage
intro that showcased some modern-looking PHP code would be great (e.g.
typescriptlang.org, golang.org). The docs design could also be
slightly tweaked to make everything seem newer, while still keeping the
(very good) content basically the same.

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

[Matthew Brown]

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

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

[Matthew Brown]

> On Sep 17, 2020, at 3:25 PM, Levi Morrison  
> wrote:
> 
> 
>> 
>> On Thu, Sep 17, 2020 at 1:00 PM Matthew Brown  
>> wrote:
>>>> On Sep 17, 2020, at 1:28 PM, Brent Roose  wrote:
>>> But I don't want to get stuck on phrasing, if elidiing is the right term as 
>>> Larry suggests, let's go with it!
>> 
>> No, the correct term is “type erasure”:
>> https://en.m.wikipedia.org/wiki/Type_erasure
> 
> "type erasure" with respect to generics means that they are checked at
> compile-time and erased at run-time. For instance, Java does generics
> through type erasure, and you had better believe those get checked at
> compile-time! This isn't what is being proposed, at least not how I
> understood it.
> 
> Really these are just "hints", but historically in PHP the term "type
> hints" meant actually type checks.
> 
> In summary:
> - Checked at run-time (and probably also compile-time when possible):
> reified generics.
> - Checked only at compile-time and thrown away at run-time: erased generics.
> - Not checked at all: ?. Maybe we can call them "ignored generics"?

Seems like Python calls this same exact behaviour type erasure:
https://www.python.org/dev/peps/pep-0484/#instantiating-generic-classes-and-type-erasure

The term term type erasure is also used in documentation for an unofficial 
Python type checker:
https://mypy.readthedocs.io/en/stable/generics.html

Looks like Hack also uses the term in this context:
https://docs.hhvm.com/hack/generics/type-erasure
(Hack’s compiler doesn’t perform any generic type-checking)

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

[Matthew Brown]

> On Sep 17, 2020, at 1:28 PM, Brent Roose  wrote:
> 
> But I don't want to get stuck on phrasing, if elidiing is the right term as 
> Larry suggests, let's go with it!

No, the correct term is “type erasure”:
https://en.m.wikipedia.org/wiki/Type_erasure

Its opposite is called reification:
https://en.m.wikipedia.org/wiki/Reification_(computer_science)

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

[Matthew Brown]

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.

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.

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.

Re: [PHP-DEV] [RFC] Global functions any() and all() on iterables

[Matthew Brown]

This would be a fantastic addition, and it would also alleviate an issue in
static analysis land where it's very tricky (in the general case) to verify
exactly what implications successfully completing a given foreach loop has
on the array being iterated over (e.g.
https://github.com/vimeo/psalm/issues/649).

Using this function would make user intent much clearer to static analysis
tools, and also (as RFC describes) increase code legibility.


On Mon, 31 Aug 2020 at 19:56, tyson andre  wrote:

> Hi internals,
>
> I've created an RFC for https://wiki.php.net/rfc/any_all_on_iterable
>
> This was proposed 2 days ago in https://externals.io/message/111711 with
> some interest
> ("Proposal: Adding functions any(iterable $input, ?callable $cb = null,
> int $use_flags=0) and all(...)")
>
> - The $use_flags parameter was removed
>
> The primitives any() and all() are a common part of many programming
> languages and help in avoiding verbosity or unnecessary abstractions.
>
> -
> https://hackage.haskell.org/package/base-4.14.0.0/docs/Prelude.html#v:any
> -
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/some
> - https://docs.python.org/3/library/functions.html#all
> -
> https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#allMatch-java.util.function.Predicate-
>
> For example, the following code could be shortened significantly
>
> ```
> // Old version
> $satisifes_predicate = false;
> foreach ($item_list as $item) {
> if (API::satisfiesCondition($item)) {
> $satisfies_predicate = true;
> break;
> }
> }
> if (!$satisfies_predicate) {
> throw new APIException("No matches found");
> }
>
> // New version is much shorter and readable
> if (!any($item_list, fn($item) => API::satisfiesCondition($item))) {
> throw new APIException("No matches found");
> }
> ```
>
> That example doesn't have any suitable helpers already in the standard
> library.
> Using array_filter would unnecessarily call satisfiesCondition even after
> the first item was found,
> and array_search doesn't take a callback.
>
> A proposed implementation is https://github.com/php/php-src/pull/6053 -
> it takes similar flags and param orders to array_filter().
>
> Thanks,
> - Tyson
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Community vote on RFCs

[Matthew Brown]

On Thu, 20 Aug 2020 at 01:42, Sergey Panteleev 
wrote:

> Hi, Benjamin,
>
> I think Nikita's suggestion is suitable for these purposes:
> https://github.com/php/php-rfcs.
>
> At the moment this is an experimental repository, but in this case, it
> will be quite possible to get feedback from the community: e.g.,
> https://github.com/php/php-rfcs/pull/1.
>
> wbr,
> Sergey Panteleev
>
>
I really liked this approach.

As a non-voting member of the PHP community, I'm generally a fan of the
status quo. I like that the people who spend time maintaining PHP generally
have the final say on new PHP features.

Honestly, I wish there were fewer eligible voters, concentrated
amongst people who have contributed internal code in the last five years.

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

[Matthew Brown]

>
>
> I don't see how that would happen.  What non-pathological case would allow
> for $foo && !$foo == true?
>
>
I suppose something a little less pathological would be

`$collection && $collection->pop() && !$collection`

which is still pretty icky (to me at least).

The other implication is that this is now possibly *not* a bug:

if (!$foo) {
  $foo->bar();
}

which, again, would ever-so-slightly reduce the effectiveness of static
analysis.

Re: [PHP-DEV] [RFC][Discussion] Objects can be declared falsifiable

[Matthew Brown]

On Tue, 14 Jul 2020 at 19:59, Josh Bruce  wrote:

> Implement an interface and magic method to allow objects to represent
> false (or empty) while still be valid instances of the custom object (type).
>
> https://wiki.php.net/rfc/objects-can-be-falsifiable <
> https://wiki.php.net/rfc/objects-can-be-falsifiable>
>
> If you saw the latest from this morning, not much has changed except
> hopefully improved formatting and now being the official mix of things.
>
> If this is your first time, the cues are taken from:
>
> - __toString()
> - Stringable
> - and __toArray() (not accepted or approved yet)
>
> Thank you for all the feedback and patience so far, appreciate it!
>
> Cheers,
> Josh


I'm not sure I love this (mostly from a static analysis standpoint).

It means that there would exist some `$foo` with the property that `$foo &&
!$foo` evaluates to true.

That seems to be a bad place for a language to go, and it would increase
the false-negative rate of static analysis tools.

Re: [PHP-DEV] [RFC] Reserve keywords in PHP 8

[Matthew Brown]

> I do not see a point in soft reserving something we don't even know if
> it will make it into 8.x. 

An enum implementation seems like something that almost certainly will make it 
into the language in the next 4 years, given PHP’s gradual adoption of features 
that already exist Hack (e.g. attributes, constructor property promotion).

While there have been many attempts to emulate enums in the language, none have 
the simplicity nor ergonomics of actual native enum support.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Keep type of reference params

[Matthew Brown]

This would break quite a lot of existing code, though PHP could add an
explicit keyword like "inout" that catches this behaviour (see example in
Hack: https://docs.hhvm.com/hack/functions/inout-parameters).

Today these issues can also be caught with static analysis:
https://psalm.dev/r/1f670956ab

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

[Matthew Brown]

>
> How much would you like/be adverse to a rector rule that changes `mixed`
> into a long union type (without `resource` in it)?



> Considering above posts, `mixed` is effectively
> `null|bool|string|int|float|array|object|resource`,
>

At runtime those things are effectively the same, but in the world of types
mixed has its own distinct meaning – I'd be very averse to any sort of
corresponding replacement.

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

[Matthew Brown]

>
> I'm not as strongly against adding "mixed" to the language as Bob, but I'm
> not convinced I'd ever bother using it.
>

I'm opposed to the use mixed in codebases – I try as best I can to remove
it from any code I come across, and a static analysis tool I've built flags
the use of mixed types whenever a more specific type is preferable. I even
have an opt-in website devoted to tracking the percentage of non-mixed
types in open-source projects, e.g.
https://shepherd.dev/github/sebastianbergmann/phpunit

Nevertheless, I think mixed should be available as a type hint for the
extreme cases mentioned in this thread (e.g. serialisation). A type system
without an explicit mixed type feels incomplete to me.

Re: [PHP-DEV] Any interest in a list type?

[Matthew Brown]

>
> IIRC, they switched from object semantics to value semantics (like PHP
> arrays). Can someone more knowledgeable confirm?
>

Yes, sorry – Hack introduced the vec type (with value semantics) in 2016
after they'd experimented first with Vector (object semantics). Use of
Vector is now discouraged.

Details here: https://github.com/facebook/hhvm/issues/6451

FB/Hack appears to be in the multi-year process of moving all PHP arrays to
one of [vec/dict/keyset]. That's likely not an option for PHP itself, but
having the _option_ of a vec equivalent (in this proposal "list") would
make sense, I think.

Re: [PHP-DEV] Any interest in a list type?

[Matthew Brown]

> This is the *design* process for a language, and it's important...
Stepping back to reconsider how collections work generally, and how we can
improve them in a graceful way that leads to a clean end-state, would be
very valuable.

Though you have much more experience with internals than I do, I think that
building a consensus around a bold new vision for PHP collections would be
a near-Sisyphean task.

Adding a list/vector type would be a much smaller, more easily definable
task – it was one of the first new types that Hack added, and by all
accounts they're pretty happy with that decision.

> Should we also be adding a dedicated dictionary type as well?

Maybe? I think there'd be less to gain from a performance standpoint
though, so I didn't want to lump that in with any list proposal and risk
derailment.

Re: [PHP-DEV] Re: Any interest in a list type?

[Matthew Brown]

>
> Anyway, I hope this was interesting and can help inform discussion and
> perhaps provide inspiration!
>

This was very useful, and it makes me feel more strongly that list should
be an entirely separate type so that checking for packed keys is rarely
necessary.

Re: [PHP-DEV] Re: Any interest in a list type?

[Matthew Brown]

> For simplicity's sake I haven't
> implemented a type declaration right now, just an is_list() function,
> but it could easily be extended to one

This is a crucial question – should is_list function like
is_numeric($some_string), where is_list just tells you about the keys in
the array at a given point in the program, or should it function like
is_int, where it tells you about the type. I lean towards the latter (which
would make the implementation of is_list simpler, but would complicate
everything else.

Re: [PHP-DEV] Any interest in a list type?

[Matthew Brown]

> map/filter/reduce need to be recast to work on any iterable, which would
then include lists
> Lists would only make sense if we're also rethinking how collections work
generally

I disagree – I think the most successful PHP language additions have been
those that allow PHP developers to improve their code without having to
think too hard – for example, property, return and param types can be added
to existing code without changing its behaviour at runtime, as long as the
added types align with actual behaviour.

If list types work in a wholly different fashion to arrays, they won't be a
drop-in-replacement, they won't feel familiar to the average PHP developer,
and I imagine few people would update existing code to use them, because
it'd be too risky.

On Wed, 22 Apr 2020 at 15:01, Larry Garfield  wrote:

> On Wed, Apr 22, 2020, at 1:49 PM, Matthew Brown wrote:
> > > Is it an effective subtype of array?
> >
> > I was thinking it should be (with the auto-conversion mentioned above),
> but
> > I can see a compelling case to not have the auto-conversion when
> > manipulating – while it would bloat the stdlib a little (we'd need a
> whole
> > bunch of list_* functions) the separation would simplify things a lot
> (e.g.
> > list_filter would return a list with sequential keys, whereas
> array_filter
> > returns an array with possibly non-sequential keys)
> >
> > And then you could cast between the two like "(list) $some_array" (which
> > would preserve order but remove keys) and "(array) $some_list" as
> > necessary. There could even be some automatic list <-> array casting when
> > calling functions not in strict_types mode.
> >
> > > Should they pass like arrays or like objects
> >
> > Definitely like arrays – I want them to be a drop-in-replacement for
> people
> > who currently use arrays in places lists are more appropriate.
> >
> > > Should they be mutable or immutable
> >
> > Definitely mutable, like arrays are
>
> That has a long list of possible issues with it relating to spooky action
> at a distance, depending on the passing semantics.  In some languages lists
> are immutable, and with PHP's copy-on-write it may make more sense to just
> go immutable.
>
> > > Are they iterable
> >
> > Yes, the keys are sequential integers
> >
> > > Does it make sense to add them without type enforcement via generics
> >
> > Absolutely – this shouldn't be tied to generics landing (which I'd
> imagine
> > is a PHP 9 feature at this point, whereas this could be a PHP 8.x
> feature).
> >
> > > can they be mapped/filtered/reduced
> >
> > Absolutely – I think we'd have list_map, list_filter, list_reduce
> functions
> > to provide that functionality.
>
> Why duplicate all of them?  Rather, map/filter/reduce need to be recast to
> work on any iterable, which would then include lists.  Or, if lists are an
> object they would be methods on the object.
>
> Hence my point.  Lists would only make sense if we're also rethinking how
> collections work generally, for which we're already overdue.  Just tossing
> them in as yet-another-different-thing would make the situation worse, not
> better.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Any interest in a list type?

[Matthew Brown]

> Is it an effective subtype of array?

I was thinking it should be (with the auto-conversion mentioned above), but
I can see a compelling case to not have the auto-conversion when
manipulating – while it would bloat the stdlib a little (we'd need a whole
bunch of list_* functions) the separation would simplify things a lot (e.g.
list_filter would return a list with sequential keys, whereas array_filter
returns an array with possibly non-sequential keys)

And then you could cast between the two like "(list) $some_array" (which
would preserve order but remove keys) and "(array) $some_list" as
necessary. There could even be some automatic list <-> array casting when
calling functions not in strict_types mode.

> Should they pass like arrays or like objects

Definitely like arrays – I want them to be a drop-in-replacement for people
who currently use arrays in places lists are more appropriate.

> Should they be mutable or immutable

Definitely mutable, like arrays are

> Are they iterable

Yes, the keys are sequential integers

> Does it make sense to add them without type enforcement via generics

Absolutely – this shouldn't be tied to generics landing (which I'd imagine
is a PHP 9 feature at this point, whereas this could be a PHP 8.x feature).

> can they be mapped/filtered/reduced

Absolutely – I think we'd have list_map, list_filter, list_reduce functions
to provide that functionality.

On Wed, 22 Apr 2020 at 13:28, Larry Garfield  wrote:

> On Tue, Apr 21, 2020, at 2:00 PM, Matthew Brown wrote:
> > Before I create an RFC or attempt a reference implementation, is there
> any
> > interest in adding (and then obviously supporting in perpetuity) a list
> > type?
> >
> > The first line of PHP's documentation for "array" states: "An array in
> PHP
> > is actually an ordered map". There are some optimisations that make
> arrays
> > with ordered integer keys faster, but I'd be interested in a separate
> type
> > dedicated to *sequential* integer keys. Such a type would presumably
> > consume a little less memory.
> >
> > Why "list" and not "vec" or similar? "list" is also a reserved word – I'm
> > imagining that you'd construct a list like
> >
> > $l = list["a", "b", "c"];
> >
> > I imagine such a "list" type would be a subtype of "array" – everywhere
> > that array was accepted, a list would be also, and it would have the same
> > copy-on-write behaviour.
> >
> > If people are interested in having that type, there's a question of what
> to
> > do with
> >
> > $some_list["a"] = 5;
> >
> > Would you convert the $some_list to an array, or throw an exception?
> > Converting to an array would seem the more PHP-like thing to do.
> >
> > Similarly, the behaviour of
> >
> > $some_list[$key_out_of_current_range] = 5
> >
> > would be a matter of debate too – would that turn $some_list into an
> array,
> > or would it fill up any preceding entries in the array with null?
> >
> > What other questions are there? Is a "list" type even a good fit for PHP,
> > given most of its users seem pretty content with the current
> > swiss-army-knife array type?
>
> Most users don't realize that PHP's arrays-not-really-arrays have caused
> millions of dollars in security breaches in the past. :-)  They're
> dangerous and to be avoided whenever possible.
>
> I'm very open to a list/sequence type, but as others have noted there's a
> whole crapload of details to sort out to make it viable.  In particular:
>
> * Is it an effective subclass of array?  IMO, no.  It should have
> absolutely no auto-conversion to/from an array whatsoever of any kind,
> period.  Keep them as separate as possible.
>
> * Should it even have random-access indexes?  Honestly I'd say no; Just
> support adding, removing, and iteration and generate the indexes on the fly
> when iterating if necessary.
>
> * Should they pass like arrays or like objects?  Many questions here.
>
> * Should they be mutable or immutable?  I could argue for either one
> effectively, I think, though I'd honestly favor immutable.
>
> * Are they iterable?  Presumably, but does that have any weird
> implications for iterables that implicitly assume there are keys?  How's
> that work?
>
> * Does it make sense to add them without type enforcement via generics?
> Lists + Generics would be lovely, but as we've seen Generics are Hard(tm)
> and Not Imminent(tm).  But would adding them now make a generic version
> harder in the future?  (I've no idea.)
>
> * Besides add/remove/iterate, what oth

Re: [PHP-DEV] Any interest in a list type?

[Matthew Brown]

Thanks for your comments!

> How would array_shift(), array_merge(array, list) ... be handled? Would
they return lists or arrays?

I think they would return lists where appropriate – Psalm & Phan already
infer some of that behaviour, adding runtime support would be an
undertaking, but not impossible.

> References to list typed properties may cause problems...

I don't see this as being any different to how integer typed properties
work under float addition (as below) – we'd just not allow any modification
that violated the list type.

class X { public int $i = 0; }
$x = new X();
$x->i += 2.3;
echo $x->i; // 2, not 2.3

With declare(strict_types=1), the above is a fatal error – the same would
be true for operations that violated list typed properties

> Having them limited to param type and return type checks

Would be happy for that compromise if the above proved confusing, or
difficult to implement



On Tue, 21 Apr 2020 at 20:18, tyson andre  wrote:

> Miscellaneous thoughts on this:
>
> - Working to have a vote on https://github.com/php/php-src/pull/4886
> might be a good first step, and something I was personally interested in
> seeing in 8.0-dev.
>   However, in the event you can't rule out that is_array($listParam) might
> not return true in the final implementation you decide on, maybe wait. (you
> said it'd be a subtype, and it seems like a lot of code would break, so
> that seems unlikely)
> - How would array_shift(), array_merge(array, list), array_intersect,
> etc., preg_match(), etc be handled? Would they return lists or arrays?
> - I'd really have liked to see data structures such as sets,
> variable-length vectors, etc. in core natively available as objects (or
> other types, but objects seemed the most practical).
>   Right now, there's php-ds https://www.php.net/manual/en/book.ds.php ,
> but if I wanted to use vec/list in an application/library that was used in
> a wide variety of places, I'd really rather have something in core. (the
> drawbacks of using a polyfill would outweigh the performance benefits for a
> small fraction of adopters)
> - If those data types were natively available, maybe opcache and/or the
> jit could use specialized opcodes to reduce the overhead of offsetGet,
> etc., if the class was known.
> - References to list iyped properties `class X { public list $list; }
> $x->list = &$localVar; unset($localVar[1]);` may cause problems in
> implementation details if they're a subtype of arrays.
>Forbidding them in typed properties and limiting the type to params and
> return types may work.
> - Having them limited to param type and return type checks (including some
> internal global function return types) would be how I'd prefer it (instead
> of adding a separate type elsewhere)
>   PHP already has special handling for iterable/callable.
> - Future scope of a list type hint might be to add a deprecation notice
> for `list ($x, $y) = $array` or `foreach ($x as list($y)) to avoid confusion
>   (even though it's currently unambiguous, and that probably will remain
> unambiguous)
>
> - Tyson

Re: [PHP-DEV] Re: Any interest in a list type?

[Matthew Brown]

>
> Making a special kind of array _value_ that must stay a “list” sounds
> more problematic… I think without automatic casting back and forth from
> regular “arrays” it might play badly with existing code, but then there
> would be no point…
>

Makes sense – then conversion from lists to arrays would happen the same way

$some_int += $some_float

converts $some_int to a float.

_If_ there was a list type then it would make sense to add a corresponding
is_list runtime check, and users would be able to typehint their functions
as returning a list, and get an error if the function actually returned a
(non-list) array.

[PHP-DEV] Any interest in a list type?

[Matthew Brown]

Before I create an RFC or attempt a reference implementation, is there any
interest in adding (and then obviously supporting in perpetuity) a list
type?

The first line of PHP's documentation for "array" states: "An array in PHP
is actually an ordered map". There are some optimisations that make arrays
with ordered integer keys faster, but I'd be interested in a separate type
dedicated to *sequential* integer keys. Such a type would presumably
consume a little less memory.

Why "list" and not "vec" or similar? "list" is also a reserved word – I'm
imagining that you'd construct a list like

$l = list["a", "b", "c"];

I imagine such a "list" type would be a subtype of "array" – everywhere
that array was accepted, a list would be also, and it would have the same
copy-on-write behaviour.

If people are interested in having that type, there's a question of what to
do with

$some_list["a"] = 5;

Would you convert the $some_list to an array, or throw an exception?
Converting to an array would seem the more PHP-like thing to do.

Similarly, the behaviour of

$some_list[$key_out_of_current_range] = 5

would be a matter of debate too – would that turn $some_list into an array,
or would it fill up any preceding entries in the array with null?

What other questions are there? Is a "list" type even a good fit for PHP,
given most of its users seem pretty content with the current
swiss-army-knife array type?

Best wishes,

Matt

Re: [PHP-DEV] Typed array properties V2

[Matthew Brown]

Yes!

Though I don't necessarily think they need to be genericised (e.g.
list) in the language itself – just having those alternate
datatypes would, I think, be a boon to the language itself – with list (a
subtype of array) more useful to me than dict.


On Sat, 18 Apr 2020 at 10:51, Sebastian Bergmann  wrote:

> Am 21.01.2020 um 22:21 schrieb Matthew Brown:
> > What if we left the array type alone, and instead focussed on "list"
> > type and "dict", "dict" types?
> >
> > That would allow a clear break from previous behaviour, and would allow
> you
> > to introduce other changes (e.g. removing string -> int coercion for
> > numeric string keys).
>
> Just to make sure I understand you correctly: are you proposing new data
> structures, names list and dict, in addition to array that can bring more
> specific / strict semantics?
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Matthew Brown]

I accept that it adds an extra level of understanding to the language – if
you see

function addAmounts($a, $b) { return $a + $b; }

you no longer definitely know the answer will be numeric.

However, I imagine that the sorts of people who will use this are _also_
the sorts of people who would add type annotations clearly – so you'd much
more likely see

function addAmounts(CurrencyAmount $a, CurrencyAmount $b) { return $a + $b;
}

where it's trivial to understand that there's userspace operator
overloading going on.

On Tue, 24 Mar 2020 at 06:04, Marco Pivetta  wrote:

> Hey Jan,
>
> Just posting here why I voted "no": it is not your implementation proposal,
> but rather the concept per-se that IMO shouldn't land in the language.
>
> Operator overloading makes call-site code reading extremely hard, and it
> makes the language much more complex for very little benefit.
>
> Everything suggested in the RFC can be done by using explicit arrows: `->`
> (method calls), which lead to expressively named methods and parameters.
>
> I have posted similar thoughts about `->__toString()` and `->toString()`
> when it comes to cast operations vs explicit calls at
>
> https://github.com/ShittySoft/symfony-live-berlin-2018-doctrine-tutorial/pull/3#issuecomment-460441229
>
> Overall, without type classes and infix functions, operator overloading is,
> IMO, just messy.
>
> Greets,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
> On Mon, Mar 23, 2020 at 6:58 PM  wrote:
>
> > Hi internals,
> >
> > I have opened voting on
> > https://wiki.php.net/rfc/userspace_operator_overloading, which allows
> > users
> > to overload operators in their own classes.
> >
> > Voting closes on 2020-04-06.
> >
> > Regards,
> > Jan Böhmer
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] [RFC][DISCUSSION] throw expression

[Matthew Brown]

I think this is great.

It reminds me of a construct that Hack introduced called "as expressions":

With throw expressions the Hack assignment,

`$a = $b as string;`

would be equivalent to the PHP assignment

`$a = is_string($b) ? $b : throw new TypeError('$b must be a string');`

If this passes, it would be great to see sugary equivalents get added to
the language too.

On Sun, 22 Mar 2020 at 12:17, Ilija Tovilo  wrote:

> Hi everybody! I hope you’re doing well.
>
>
>
> Due to the modest feedback I’d like to move the throw expression RFC to
> “under discussion”.
>
> https://wiki.php.net/rfc/throw_expression
>
>
>
> In short, the RFC proposes to convert the throw statement into an
> expression to make it usable in arrow functions, the coalesce operator, as
> well as the ternary/elvis operator.
>
> If you have any feedback, concerns, or if you want to express your
> interest or lack thereof, let me know!
>
>
>
> Regards
>
>
>
>

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

[Matthew Brown]

I don't think it's conflicting _if you insist on brackets_ after the new
expression. PHP Parser grammar for "new" expressions is

T_NEW class_name_reference ctor_arguments

If you allowed the shorter syntax, ctor_arguments would allow an
object_properties entry.

I'm sure Nikita could clarify, though.


On Mon, 16 Mar 2020 at 21:13, Jakob Givoni  wrote:

> On Mon, Mar 16, 2020 at 9:10 AM Matthew Brown 
> wrote:
> > I love the idea!
> Thanks Matthew!
>
> > The syntax for new objects looks a little verbose – would it be possible
> to use
> >
> > $foo = new Foo()[
> >   property1 = "hello",
> >   property2 = 5,
> > ];
> The short answer: I don't think so.
>
> This is not possible (though it's arguably 'nicer'):
>
> new Foo()->doSomething(); // syntax error, unexpected '->'
>
> Not sure why, but it's necessary to wrap the instantiation in brackets:
>
> (new Foo())->doSomething(); // Ok
>
> If someone can explain why, it would be enlightening!
>
> Furthermore, dropping the arrow would create conflicting syntax with
> array access:
>
> $foo[1]; // Array access, give me the element with index 1, can be
> used on objects as well
> $foo[a = 1]; // Property assignment... ???
>
> I'll update the RFC to reflect your proposal.
>
> Thank you,
> Jakob
>

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

[Matthew Brown]

I love the idea!

The syntax for new objects looks a little verbose – would it be possible to
use

$foo = new Foo()[
  property1 = "hello",
  property2 = 5,
];

as an alternative to

$foo = (new Foo())->[
  property1 = "hello",
  property2 = 5,
];


On Mon, 16 Mar 2020 at 07:48, Jakob Givoni  wrote:

> Hello Internals,
>
> I'm opening up my new RFC for discussion:
>
> https://wiki.php.net/rfc/compact-object-property-assignment
> - A pragmatic approach to object literals
>
> Let me know what you think!
>
> Best,
> Jakob
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Attributes v2

[Matthew Brown]

I would not expect someone who’s never written a line of code to understand 
attributes/decorators, just as I wouldn’t expect them to understand traits, 
interfaces, or really any of the things one should know about in order to write 
and maintain production-ready PHP code.

If you want someone to get excited about programming, PHP is probably not the 
best language for them to start with. There are a ton of great interactive 
online tools (e.g. Glitch, CodePen) that make it easy to get started without 
having to worry about installing PHP or mastering the language’s syntax.

> On Mar 9, 2020, at 9:48 PM, Mike Schinkel  wrote:
> 
> 
>> 
>> On Mar 9, 2020, at 9:36 PM, Matthew Brown  wrote:
>> 
>> Saying "the syntax makes my eyes bleed" is slightly useless feedback.
> 
> That was just a header.  There was elaboration right below it:
> 
> "I find angle brackets extremely hard to read and fear — having trained many 
> newbies in programming — that it will cause newbies who see PHP to think it 
> is too complex for them to consider learning."
> 
> And there was a proposed alternative.
> 
>> You could say "it's hard to scan", but I don't even think that's true – 
>> prepending everything << makes it easy to pick out attributes in plain text 
>> at a glance,
> 
> Not for me.  Seeing the word "attributes" is far easier for me than seeing 
> "<<" and ">>."   
> 
> I do of course understand YMMV.
> 
>> Additionally this syntax has effectively been battle-tested at scale already 
>> in PHP-like codebases – thousands of engineers at Facebook and Slack have 
>> used it over the last few years, and been productive with it.
> 
> Yeah, developers who have been vetted by two very successful tech companies. 
> 
> Something tells me neither of them hire moderately-to-lower skilled 
> developers who work in the trenches at many non high-flying tech companies, 
> nor do they hire newbies who are trying to decide if they should learn PHP, 
> or learn Javascript/Typescript instead (for example.)
> 
> Just registering my objection to the syntax and proposing a readable 
> alternative.  I would be highly surprised if there were not many others in 
> userland who would feel the same.  But of course I unfortunately have no way 
> of validating that belief.
> 
> -Mike

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

Re: [PHP-DEV] [RFC] Attributes v2

[Matthew Brown]

Saying "the syntax makes my eyes bleed" is slightly useless feedback.

You could say "it's hard to scan", but I don't even think that's true –
prepending everything << makes it easy to pick out attributes in plain text
at a glance, and one can assume that IDEs will help even further.

Additionally this syntax has effectively been battle-tested at scale
already in PHP-like codebases – thousands of engineers at Facebook and
Slack have used it over the last few years, and been productive with it.

On Mon, 9 Mar 2020 at 21:02, Mike Schinkel  wrote:

> > On Mar 9, 2020, at 10:42 AM, Benjamin Eberlei 
> wrote:
> >
> > Hi all,
> >
> > I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
> > 2016 with a few changes, incorporating feedback from the mailing list
> back
> > then and from talking to previous no voters.
> >
> > The RFC is at https://wiki.php.net/rfc/attributes_v2
> >
> > A working patch is at https://github.com/beberlei/php-src/pull/2 though
> > work around the details is still necessary.
> >
> > The RFC contains a section with common criticism and objections to
> > attributes, and I hope to have collected and responded to a good amount
> > already from previous discussions.
> >
> > There is also a fair amount of implementation detail still up for debate,
> > which is noted in "Open Issues". I have pre-committed to one approach,
> but
> > listed alternatives there. On these issues I am looking for your
> feedback.
> >
> > greetings
> > Benjamin
>
> I am very excited to see this. I make heavy use of pseduo-attributes in
> both PhpDoc and using class constants, and having real attributes would be
> quite the boon.
>
> I do have a few concerns.
>
> 1. The syntax makes my eyes bleed.
> ---
>
> I find angle brackets extremely hard to read and fear — have trained many
> newbies in programming — that it will cause newbies who see PHP to think it
> is too complex for them to consider learning.
>
> You mention that the good symbols are taken, but why limit ourselves to
> symbols?  Why not use words like PHP uses for other parts of the language?
>
> So instead of:
>
> <>
> <>
> <<\My\Attributes\FewArguments("foo", "bar")>>
> function foo() {}
>
> Why not use?:
>
> attribute SingleArgument("Hello")
> attribute Another\SingleArgument("World")
> attribute \My\Attributes\FewArguments("foo", "bar")
> function foo() {}
>
> If we don't want to make attribute a keyword, why not this?:
>
> function attribute SingleArgument("Hello")
> function attribute Another\SingleArgument("World")
> function attribute \My\Attributes\FewArguments("foo", "bar")
> function foo() {}
>
> Or?:
>
> function attributes
> SingleArgument("Hello"),
> Another\SingleArgument("World"),
> \My\Attributes\FewArguments("foo", "bar")
> function foo() {}
>
> Alternately, why not use this (which is probably the best option IMO)?:
>
> function foo() attributes
> SingleArgument("Hello"),
> Another\SingleArgument("World"),
> \My\Attributes\FewArguments("foo", "bar") {}
>
>
> 2. How do your attributes relate to traits and interfaces?
> ---
>
> I assume that anything you could do in a class you could do in a trait,
> but what about interfaces?
>
> Using my syntax, could we have attributes defines in an interface and then
> require them to be implemented?  For example,
>
>
> interface Storable attributes
>StorageEngine(string $engine),
>DoNotTestMethodsPrefixedWith(string $prefix){
>function store() attributes PermissionsRequired(string $role) {}
> }
>
> When implemented that might look like this:
>
> class AdminOnly() implements Storable attributes
>StorageEngine("mongodb"),
>DoNotTestMethodsPrefixedWith("_"){
>function store() attributes PermissionsRequired("admin") {}
>...
> }
>
> Other than those two concerns, I'm sold!
>
> -Mike
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Attributes v2

[Matthew Brown]

For information that's needed at runtime (as opposed to documentation or
static analysis) docblocks have an obvious overh

I think the syntax here looks great, and I think this would be an exciting
addition to the language. I want to build things with it!

On Mon, 9 Mar 2020 at 10:43, Benjamin Eberlei  wrote:

> Hi all,
>
> I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
> 2016 with a few changes, incorporating feedback from the mailing list back
> then and from talking to previous no voters.
>
> The RFC is at https://wiki.php.net/rfc/attributes_v2
>
> A working patch is at https://github.com/beberlei/php-src/pull/2 though
> work around the details is still necessary.
>
> The RFC contains a section with common criticism and objections to
> attributes, and I hope to have collected and responded to a good amount
> already from previous discussions.
>
> There is also a fair amount of implementation detail still up for debate,
> which is noted in "Open Issues". I have pre-committed to one approach, but
> listed alternatives there. On these issues I am looking for your feedback.
>
> greetings
> Benjamin
>

Re: [PHP-DEV] Bug Wrong resolution of "Late Static Binding" after self::method()

[Matthew Brown]

This is expected behaviour given my understanding of how late static binding 
works:

If there is a chain of “self::” calls that ultimately ends in 
“static::someMethod”, then PHP behaves as if every preceding call was a call to 
“static::”, not “self::”. In your second call you’re explicitly overriding that 
resolution by changing using (self::class)::someMethod, which PHP always treats 
as A::someMethod, thus producing the expected output.

> On Mar 8, 2020, at 4:48 AM, Marc  wrote:
> 
> Hi,
> 
> I have reported a bug in Mai 2019 but did not get any response here 
> https://bugs.php.net/bug.php?id=77985.
> 
> 
> The problem is that "static::class" as well as "get_called_class()" used 
> within a method resolves to a different class if this method was called with 
> "self::method". Interestingly it works as expected if the method got called 
> with "ClassName::method".
> 
> 
> I send it here because fixing this could result in a hard to find BC break 
> and it could be a good idea to handle this in 8.0.
> 
> 
> https://3v4l.org/NSdB8
> 
> class A {
> static function call() {
> self::method();
> 
> $self = self::class;
> $self::method();
> }
> static function method() { echo static::class; }
> }
> 
> class B extends A {}
> 
> B::call(); // displays "BA" instead of "AA"
> 
> 
> In case this is "Not a Bug" please explain to me why the result of 
> "self::method()" is different then "$self = self::class; $self::method();".
> 
> 
> Thanks,
> 
> Marc
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

Re: [PHP-DEV] [RFC] Explicit call-site pass-by-reference (again)

[Matthew Brown]

This proposal is great, but most PHP static analysis tools already do a
reasonable job of understanding by-reference assignment and detecting bugs
there (an exception is closure use by-reference checks, which is a
static-analysis no-man's land).

No static analysis tools catch your specific use-case, though.

On Thu, 20 Feb 2020 at 09:48, Levi Morrison via internals <
internals@lists.php.net> wrote:

> Just chiming in to voice strong support for this RFC. This is a key
> piece toward making PHP code statically analyzable. If it becomes
> required at the call site, such as in an edition of the language, it
> will significantly enhance the ability to reason about code and
> probably make it more correct as well. As a small example, consider
> this method on an Optional type class:
>
> function map(callable $f): Optional {
>   if ($this->enabled) {
> return new Optional($f($this->data));
>   } else {
> return $this;
>   }
> }
>
> The intent is to return a new optional or an empty one, but if you
> pass a closure that accepts something by reference you can change the
> original, which is not intended at all. For people who defend against
> it, it requires saving `$this->data` to a local variable, then passing
> in the local. Then if the user does a call-by-reference it will affect
> the local, not the object's data.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Matthew Brown]

Someone recently requested something similar for a PHP static analysis tool
I wrote (https://psalm.dev/r/f75997a263), though that version only allows
lazy initialisation inside the class in which a given property is declared.

Personally I don't like either approach – I think per-property getters and
setters would be a more appropriate venue for this functionality, something
like:

property int $s {
public get;
private set;
}

This pattern could also be extended to support per-property getter and
setter methods.

On Wed, 19 Feb 2020 at 12:06, Máté Kocsis  wrote:

> Hi Internals,
>
> I'd like to move my RFC forward to the discussion phase:
> https://wiki.php.net/rfc/write_once_properties
>
> In short, I propose to add support for a new property modifier that would
> allow properties to be initialized, but not modified afterwards.
>
> Cheers,
> Máté Kocsis
>

Re: [PHP-DEV] Typed array properties V2

[Matthew Brown]

> As far as I know, the only viable way to do that is to make the array
> intrinsically typed, which means that types are validated when elements are
> inserted into the array, not when it is passed across a function boundary.
> In other words, array generics.
>

What if we left the array type alone, and instead focussed on "list"
type and "dict", "dict" types?

That would allow a clear break from previous behaviour, and would allow you
to introduce other changes (e.g. removing string -> int coercion for
numeric string keys).

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

[Matthew Brown]

Though this is truly a stylistic complaint, I think it will lead to
harder-to-analyse code.

Currently I have a static analysis tool that can verify (in 99% of cases)
whether all properties of a class have been initialised in the constructor.
This check is even more important in PHP 7.4, where use of a property
without instantiation is a fatal error.

Figuring out which properties have been instantiated in a constructor is
non-trivial, and it's only efficient to do it once per class.

If we adopt this into the language and people use both __construct and
object initializers for a given class, analysis would become much more
tricky.

In order to find the error in this:

abstract class A {
  public string $s;
  public int $t;
}

class B extends A {
  public bool $u;

  public function __construct() {
$this->s = "hello";
  }
}

$b = new C {
  u = true
};

The analyzer needs to understand that the initialisation of B left a
property uninitialised - it warns about it in B's constructor (
https://psalm.dev/r/0e8e40fefc) but I worry that people will start to
dismiss those warnings as false-positives if this pattern becomes popular.

Best wishes,

Matt




On Thu, 12 Sep 2019 at 10:00, Michał Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

> Hi internals,
>
> I'd like to open discussion about RFC: Object Initializer.
>
> This proposal reduces boilerplate of object instantiation and properties
> initialization in case of classes without required constructor arguments as
> a single expression with initializer block.
>
> https://wiki.php.net/rfc/object-initializer
>
> I appreciate any feedback you all can provide.
>
> Thanks,
> --
> Michał Brzuchalski
> brzuc...@php.net
>

Re: [PHP-DEV] Changing fundamental language behaviors

[Matthew Brown]

I'm sure that some people wrote code like this, expecting it to always work
in PHP:

if ($some_condition) define("HELLO", 0);
if (HELLO) { var_dump("got here"); }

The equivalent, relying on buggy behaviour, PHP code looks like

if ($some_condition) $hello = 1;
if (!$hello) { var_dump("got here"); }

If preventing undefined constants wasn't a fundamental change to the
language, neither is preventing undefined variables.

>

Re: [PHP-DEV] Changing fundamental language behaviors

[Matthew Brown]

>
> What if Java suddenly said that all properties are suddenly private, and
> can only be accessed through getter/setter methods?
>

If Java announced that the next major version was to make the change after
95% of userland developers favoured it and over 2/3rds of their internals
team did, I'd think "huh ok I guess they have good reasons".

For 20 years people have developed code based on that feature. It was never
> considered an error, and often not even considered bad practice


You seem to be arguing against *ever* changing something that a majority
once thought was good, and fundamental to a given system. Lots of things
fall into that category - restricting voting to men, segregation, etc.

>

Re: [PHP-DEV] Changing fundamental language behaviors

[Matthew Brown]

>
> that don't fundamentally change the language


There's clearly a big disagreement about whether this is a fundamental
change or not.

Preventing something that the entire field of software engineering frowns
upon (and that most PHP developers avoid like the plague) doesn't seem like
a *fundamental* change.

Re: [PHP-DEV] Changing fundamental language behaviors

[Matthew Brown]

Without your contributions in the early 2000s, PHP likely would not enjoy
the popularity it does today.

But I don't think that gives you veto power over the entire process. You
haven't made any significant contributions to the codebase in over a
decade, and yet the language has still gained many more users in that time
frame, with some fairly major backwards-incompatible changes along the way.

I think you have to come to terms with the fact that today you are a single
vote in this process — though you are, of course, free to write your own
RFCs.

Best wishes,

Matt

On Thu, 12 Sep 2019 at 10:44, Zeev Suraski  wrote:

> I was really really hoping that we will avert having to dive into this and
> instead go for the alternative solution that was proposed of changing
> default php.ini error levels.  But since the RFC went on to a vote - we
> need
> to make something clear.
>
>
>
> The RFC process was never, ever meant to handle fundamental changes to the
> language.  It was meant to deal predominantly with additions to the
> language, as can be inferred from numerous parts in the phrasing.  As I
> mentioned in the past - it wasn't even intended to deal with simpler
> deprecations, but it appears that the cat is out of the bag on this one.
> However, the fact the cat is out, doesn't mean we'll let a tiger waltz out
> of the same bag.  Using the RFC to deprecate fundamental behaviors of the
> language - such as how the language deals with undefined variables - is
> simply off the table.
>
>
>
> You may be wondering, in that case, what processes do we have to deal with
> such changes then?  The answer is simple.  We don't.  We don't have to have
> them either - the fundamental language behaviors are here to stay.
>
> Deprecating the ability to rely on the expected default value of
> uninitialized variables falls squarely in that category.
>
>
>
> Reclassifying a notice to a warning is a possibility - people's code will
> still run, and they'll be able to continue using these behaviors going
> forward as well if they want to (perhaps with minor tweaks to error
> reporting levels).  Turning a notice to an error isn't reclassifying an
> error level.  It's deprecating a behavior - and we're not talking about
> some
> esoteric extension, but a documented, well-defined, fundamental behavior of
> the language for over two decades.  The fact many of you think it's
> horrible
> does not change that.  Deprecating such fundamentals is simply outside of
> the mandate of internals@, regardless of whatever majority appears to
> exist
> in favor of it at a given time.
>
>
>
> Similarly - adding typed variables - is certainly a future option.
> Changing
> PHP to require typed variables (without opting in) - is well outside of the
> internals@ mandate.
>
>
>
> For areas like that - our options are either doing nothing, or providing
> opt-in mechanisms to cater to stricter-loving audiences.  I'm all for the
> 2nd option, but there is no 3rd.
>
>
>
> Zeev
>
>
>
>

Re: [PHP-DEV] [RFC] Union Types v2

[Matthew Brown]

- Agree on the usefulness of a stringable meta-type.

- Hack supports an explicit “: this” return type (without dollar) when 
returning “new static(...)”. I think I might prefer that to “: static”.

- From a type perspective, I don’t understand the “int|void” idea - it might 
make your users’ life easier, but doesn’t accord with how PHP works (which 
treats void as null to consumers).

- if we’re adding to some future wish list, would love to have support for “: 
noreturn” when a function always throws or exits

On Sep 4, 2019, at 5:58 AM, Nicolas Grekas  wrote:

>> 
>> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md
> 
> 
> Thank you Nikita, this would be a hugely welcomed step forward! Can't wait
> to get rid of all those docblock annotations!
> 
> I've some additional suggestions that would greatly help remove more
> docblocks and provide engine-enforced type-safety, maybe for the "future
> scope" section. We use the all in Symfony:
> 
>   - we miss a stringable union type, for `string|__toString`. This is
>   required when an API need lazyness regarding the generation of some
>   strings. Right now, we have no other option but using string|object.
>   - we use "@return $this" quite often. On the implementation side, I'd
>   suggest enforcing this at compile time only (enforce all return points are
>   explicit, and written as "return $this", similarly to what is done for
>   nullable/void return types.) This makes sense only for return types.
>   - we use "@return static" quite often too, typically when a method
>   returns a clone of the current instance. If anyone wonders, this is not the
>   same as "@return self" of methods overridden in child classes. This makes
>   sense only for return types.
> 
> About union types with void in them, we do use one in Symfony:
> Command::execute() has "@return int|void". The reason is that if we were to
> use "?int" instead, the engine would force the community to add "return
> null;" where no return statement is needed at all most of the time. Right
> now, we consider that the transition cost for the community is not worth
> the extra boilerplate this requires. Note that there would be only one
> friendly path forward: trigger a deprecation when null is returned, asking
> ppl to add  "return 0;". Not sure how this should impact the proposal, but
> I thought it could be worth sharing.
> 
> Thanks again,
> Nicolas

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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Matthew Brown]

I don’t think it’s helpful to compare C#’s BC policies to PHP’s. C# is used 
today mostly as its architect intended at its founding. PHP, having 
transitioned from a templating system to a fully-fledged language, is used 
quite differently.

> On Aug 29, 2019, at 11:50 AM, Chase Peeler  wrote:
> 
>> On Thu, Aug 29, 2019 at 10:22 AM Zeev Suraski  wrote:
>> 
>> On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals <
>> internals@lists.php.net> wrote:
>> 
>>> I know what the manual says about notices. But I don't agree with
>>> interpreting "could happen in the normal course of running a script" as
>>> "it's perfectly fine if this part of your code triggers a notice
>>> consistently and every time it goes down this particular code path".
>>> Rather, I've always interpreted this as "under certain, rare, unforeseen
>>> circumstances, your code could generate a notice here, probably because
>> of
>>> something that is outside of your control".
>>> 
>>> That's how I've always treated them at least.
>>> 
>> 
>> And that's entirely within your right to do so - but what the manual says
>> is accurate.  Calling me delusional in my interpretation of it is somewhat
>> awkward (to put it mildly), I have a pretty good idea of why we added the
>> different error levels - I wrote much of it myself.
>> 
>> The whole point of having notices as something that's separate from
>> warnings is that they have different semantics, and that semantics is
>> captured very accurately in the manual.  They are used to mark issues which
>> may be problems, but may also be perfectly fine (unlike warnings, which
>> generally speaking mean that something bad happened, but not bad enough to
>> halt execution).  Notices were meant to help you implement a more strict
>> style of coding, and they may help you catch certain types of bugs, but you
>> can have perfectly working, bug-free code that generates notices.
>> 
>> Regardless of the exact semantics, don't you think a program that generates
>>> a constant stream of notices is a bit strange? That sounds like something
>>> everyone would naturally want to avoid. You don't drive your car with the
>>> check engine light permanently on and say "this is fine", right?
>> 
>> 
>> Except you can purposely turn off this 'check engine' light, never to see
>> it again if you choose to.  And that it's really not at all similar to
>> 'check engine', but a lot closer to 'check cleaning fluid', or even 'clean
>> windshield' (if cars had a dashboard light for that).  Even that is not a
>> good analogy - as folks often actually purposely write code that generates
>> notices (which would be purposely hidden, either by error_reporting setting
>> or using @) that is 100% bug-free and working as intended.  So no, there's
>> nothing strange about it if you buy into that approach.  If you don't (and
>> I know you don't) - that's absolutely fine - it's up to you.
>> 
>> Zeev
>> 
> I just wanted to bring up a few other points. First, as I think Stanislav
> has done a good job of pointing out, the flexibility of PHP is one of its
> greatest features. The nice thing about a flexible and forgiving language
> is that you can always put additional things in place on top of it to make
> it more strict and rigid if you want. Once you force a language to be
> strict and rigid, however, it's much harder, if not impossible, to add back
> in flexibility.
> 
> A lot of my emails on this thread have been focused on the burden to
> developers caused by the BC break. While I still think that is an important
> consideration, it distracted me from my initial view which was we shouldn't
> do this because it's just a bad idea. I understand all of the arguments for
> enforcing variable initialization. I agree with most of them as well.
> However, I think there are a myriad of ways that individuals and teams can
> do that enforcement without forcing it on every single developer whether
> they want it or not.
> 
> A lot of comparisons have been made to other languages. I do a lot of work
> with javascript and I have a good amount of experience with c# as well.
> I've used many other languages at times (c, c++, java, perl, ruby, etc.) as
> well. In c#, you don't have to initialize your variables - you have to
> declare them. Some types, like ints, are automatically initialized to 0
> unless explicitly initialized to something else. PHP doesn't require you to
> declare variables. So, while c# might require "int i; i++;" you can achieve
> the same thing in PHP with "$i++;" - neither one requires an explicit
> initialization.
> 
> A few people have referred to the fact that I have instances of undeclared
> variables as technical debt. As I said earlier, I've engaged in these
> discussions because I don't think just calling something technical debt
> should be justification for a change. The fact that a large number of
> developers might have technical debt in a certain area should be considered
> when weighing the pros and cons of a 

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Matthew Brown]

$foo++ becoming 1 when $foo is undefined is not intuitive to me.

To take a very trivial example, that behaviour causes “for ($i = 0; $i < 10; 
$I++) {}” to loop indefinitely.

> On Aug 28, 2019, at 6:52 PM, Stanislav Malyshev  wrote:
> 
> Hi!
> 
>> This is where I think PHP may have broken us a little.
> 
> I think it's in no way "broken" to be able to easily match expectations,
> like $foo++ always do what you meant without clunky boilerplate.
> Also, if you think PHP is the only language I program in daily (and I
> mean every day, except some weekends and vacations maybe) you're wrong
> :) I have something to compare to, so what I say some things are easier
> in PHP that's because I actually compared.
> 
>> I just asked a few non-PHP developers here what they expect "(function
>> () { $a++; })()" to do, and they agreed it would be some sort of error.
>> Got the same answer for "(function () { $a->bar = 5; })() ".
> 
> I see absolutely no reason for it. Maybe if you're a Java programmer who
> never saw non-statically-typed non-B language - but that's not a
> virtue we should be striving to emulate. If we have a tool that already
> does things better and some people don't even know such tools are
> possible, we should educate them, not break our tools so it would be
> more comfortable fit to their experience.
> 
>> Indeed, anyone who's used another C-like language (JS, TS, Java, C# etc)
>> is used to these things being errors, so it can be disorientating to see
> 
> I don't think having things just work instead of usual boilerplate that
> you have to declare everything upfront and repeat even obvious things
> numerous times is "disorienting" in any way. If you check how languages
> that are alive evolve (like Java or C++, C is mostly fossilized these
> days), even strict ones, you see they support more and more intuitive
> approaches - like auto variables for example - which make things easier.
> Because human should spend time thinking, not figuring out how to
> satisfy a dumb compiler. That's the direction we should be moving to.
> Not adding more errors and boilerplate in clear cases like $foo++.
> 
> -- 
> Stas Malyshev
> smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Matthew Brown]

This is where I think PHP may have broken us a little.

I just asked a few non-PHP developers here what they expect "(function () {
$a++; })()" to do, and they agreed it would be some sort of error. Got the
same answer for "(function () { $a->bar = 5; })() ".

Indeed, anyone who's used another C-like language (JS, TS, Java, C# etc) is
used to these things being errors, so it can be disorientating to see them
treated as anything else by PHP (it was disorientating for me, at least).

On Wed, 28 Aug 2019 at 18:06, Stanislav Malyshev 
wrote:

> Hi!
>
> > If we want PHP to be as easy as possible then $nullref->bar(),
> > $foo->someUndefined(), new UndefinedClass etc shouldn’t be exceptions
> > either - they can just be notices.
>
> I don't see how it follows. Calling unknown method does not have natural
> default - if I tell you "would you please do abracadabra" you can't just
> do something random and consider it done - you should tell me "what do
> you mean by that? Please explain what you want me to do".
> However, if I tell you "here's an apple, add it to your pocket", then
> there's a natural way of knowing how many apples is in your pocket for
> every state of your pocket before - if your pocket was empty, it now has
> one apple, if it had apples before, now it has one more. I don't need to
> explain you what to do when your pocket is empty and when it's not
> separately - you can guess intuitively what should happen in each case
> and you'd be 100% right always.
>
> That's the natural difference between $foo++ and foo() - in the former
> case, you know what should happen in any case (including when $foo is
> initialized to a non-numeric value - *then* you error out), in the
> latter, if foo() is not defined, there's no natural way to go but to
> error out. There's a crucial difference here because variables are
> containers, not actors. Dealing with an empty container has natural
> semantics (in some cases at least), dealing with non-existing actor does
> not.
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Matthew Brown]

If we want PHP to be as easy as possible then $nullref->bar(), 
$foo->someUndefined(), new UndefinedClass etc shouldn’t be exceptions either - 
they can just be notices. 

> On Aug 28, 2019, at 4:01 PM, Stanislav Malyshev  wrote:
> 
> Hi!
> 
>> Javascript has treated undefined variables as a catchable exceptions since
>> (I think?) forever.
> 
> Which seems to be why I open a random Javascript file in our codebase
> and see this:
> 
> var wikibase = wikibase || {};
> wikibase.queryService = wikibase.queryService || {};
> wikibase.queryService.ui = wikibase.queryService.ui || {};
> wikibase.queryService.ui.toolbar = wikibase.queryService.toolbar || {};
> 
> wikibase.queryService.ui.toolbar.Actionbar = ...
> 
> (not my code but I've seen it a lot)
> IMHO, this is language getting in a way and people writing boilerplate
> to avoid "service" that is not actually needed.
> 
>> much work. This means its developers often don't improve much either, which
> 
> I don't think PHP should be a language that "builds character" by
> forcing people to do more work than it's necessary for them, in order
> for them to "improve". I think it should be as easy as possible, and if
> somebody wants to learn how the bits move, one can always pick up a good
> book or go to a Coursera course, etc.
> 
> -- 
> Stas Malyshev
> smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Matthew Brown]

Javascript has treated undefined variables as a catchable exceptions since
(I think?) forever. Perl is the only other language I know that allows them.

I've written code in a lot of different languages. Many of those languages
(most notably Standard ML) forced me to think about how exactly data flowed
through my program. PHP, on the other hand, doesn't demand anything like as
much work. This means its developers often don't improve much either, which
ultimately this harms the language's reputation as former PHP developers
discover their bad habits don't translate well to other languages.

With this change we can make it harder for people to write bad code, which
I think will result in existing PHP users becoming better developers.

On Wed, 28 Aug 2019 at 14:32, Zeev Suraski  wrote:

>
>
> On Wed, Aug 28, 2019 at 8:20 PM Matthew Brown 
> wrote:
>
>> We log 1 in every 1000 notices, and yes - being notice-free is a goal –
>> though not one with any particular timeline at the moment, because we can
>> just ignore the problem. I look forward to not being able to ignore the
>> problem.
>
>
> When was this goal set?  Was there effort that went into it?
>
> My point is this:
>
> In a codebase where being notice-free isn't a goal - and/or where code
> patterns that rely on the documented behavior of how PHP variables are
> initialized as well as behave in read scenarios (with or without the
> silence operator) - I think you're going to find a lot of such instances,
> probably more so than in a company that made an informed decision to not
> allow it and gradually work to remove existing code that uses it.  For
> many, this is not considered technical debt - but rather - using the
> language *as intended*.  Using the language in a way that is sanctioned and
> considered valid - alongside other ways which are also considered valid
> (e.g. a notice-free codebase).
>
> While I understand what you're saying when you say that you look forward
> to not being able to ignore the problem, it sounds like a fairly weak
> argument for forcing everyone else - many of whom don't consider this to be
> a problem at all - to change their code.  Instead, if this bothers you,
> make an informed decision to change - there's enough tooling to do that
> today with reasonable effort.  Or support the ability to flip a switch that
> will granularly force you to fix these particular issues.  Forcing all
> users to work in a certain way, because some of the users who want to work
> that way can't bring themselves to do it - doesn't sound very sensible IMHO.
>
> I was hoping that the glaring obviousness of how other languages tackled
> similar issues (Perl, JS) would go a longer way.  It should.
>
> Zeev
>

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Matthew Brown]

I'm no management expert, but I'd be surprised if a boss who won't set
aside time to fix a few undefined variables nevertheless green-lights
rewriting everything in C#.

On Wed, 28 Aug 2019 at 12:26, Chase Peeler  wrote:

> On Wed, Aug 28, 2019 at 12:12 PM Mark Randall  wrote:
>
> > On 28/08/2019 16:37, Chase Peeler wrote:
> > > I'm also not the one that built it on the eggshells - I'm just the one
> > that
> > > is now in charge of developing the system that someone else left
> sitting
> > > eggshells.
> >
> > That's a challenge which at some point or another will face all
> > technical leads.
> >
> > You have to go to the people making the decisions and say:
> >
> > "Okay, look, we've got ourselves a problem here. We've dug ourselves
> > into a hole by cutting corners, building up debt, and we've never made
> > it a priority to fix it, and now it's causing us problems. It's not one
> > person's fault, it's something that has collectively developed over
> > time, but the reality is, the problem is there and needs fixing."
> >
> > But that's a lie. We have made it a priority to fix things that are
> broken. I wouldn't consider undeclared variables cutting corners. We've
> also invested a lot into making sure we aren't building up additional
> technical debt with the new stuff we're fixing.
>
>
> > And when the manager asks "What problems?" you say something like:
> >
> > "The language we use is moving towards a much stricter approach to
> > handling ambiguous or error prone code. This can only be considered a
> > good thing, but it is going to mean that a lot of our technical debt is
> > going to manifest as errors that will stop our site from function..."
> >
> > Then the manager will go "Can't we just keep using the version we are
> on?"
> >
> > You reply:
> >
> > "We can for a short period, perhaps an extra year or two, but the
> > reality is that PHP is moving forward, and the current version won't be
> > supported forever, and even if it were, we would be missing out on major
> > performance enhancements and new features that could help us to build
> > new features".
> >
> > Or, they go "Maybe we should look at some options that aren't always
> breaking things. Our other system built with C# has never had that issue."
>
>
> > The manager says: "Lay this out to me"
> >
> > You reply:
> >
> > "It's like our company car still works, but it no longer tighter meets
> > emissions standards so they won't let us take it into the city any more"
> >
> > In this case, it's like "Our car still works, but, you the left/right
> arrows on the volume knob have worn off, so, you can't tell by looking at
> it whether you turn it clockwise or counter clockwise to turn up the
> volume.
>
>
> > "Crap", the boss replies "Okay, we had best fix that"
> >
> > Boss replies "Yea, that sounds like a pretty stupid reason to have to
> upgrade. We'll wait."
>
>
> > --
> > Mark Randall
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
>
> --
> Chase Peeler
> chasepee...@gmail.com
>

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Matthew Brown]

Kicking a house is a poor analogy IMO - most people don’t upgrade a major
language version without first verifying that their code still works in the
new version.

And the PHP ecosystem is strong – it's possible to find out today if your
code is likely to break (on undefined variables) with both static analysis
tools and runtime error handlers.


On Wed, 28 Aug 2019 at 13:24, Rowan Collins  wrote:

> On 28 August 2019 17:53:55 BST, Matthew Brown 
> wrote:
> >It's not breaking all the things - it's breaking code that should have
> >been broken already, but somehow wasn't.
>
>
> It's still breaking it though.
>
> If you realise that a house is built badly and could be destroyed by a
> well-aimed kick, you could just give it a kick and say "ah well, not my
> fault"; or you could warn the owners, offer help in fixing it, and
> understand that they might be too busy to do it right away.
>
> I don't see why it needs to be such a big deal to ask if this is something
> we actually need to kick, right now.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Matthew Brown]

We log 1 in every 1000 notices, and yes - being notice-free is a goal –
though not one with any particular timeline at the moment, because we can
just ignore the problem. I look forward to not being able to ignore the
problem.

On Wed, 28 Aug 2019 at 12:55, Zeev Suraski  wrote:

>
>
> On Wed, Aug 28, 2019 at 5:22 PM Matthew Brown 
> wrote:
>
>> Looking at our notice logs, I estimate (fairly roughly) that it would
>> require about a week's worth of my time to fix these issues in vimeo.com
>> ’s
>> 700K LOC codebase (the undefined variables are confined to our views).
>>
>
> Can you elaborate a bit about how you generally deal with notices in
> vimeo.com - are you generally aiming to be notice-free?  Or is that log
> collecting a huge amount of messages?
>
> Zeev
>

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Matthew Brown]

It's not breaking all the things - it's breaking code that should have been
broken already, but somehow wasn't.

On Wed, 28 Aug 2019 at 12:38, Rowan Collins  wrote:

> On 28 August 2019 16:05:13 BST, Marco Pivetta  wrote:
> >A week for 700KLOC is *impressively low*.
> >Many organisations spend more time on *deciding* whether to upgrade a
> >patch
> >version of a dependency, and the tooling that vimeo has provided to
> >detect
> >these issues is technically impressive, and very much usable by other
> >orgs
> >too.
>
>
> I literally have no idea what to take from that response. Some
> organisations are slow, some have cool workflows, so let's break all the
> things?
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Matthew Brown]

FWIW: all the runtime notices in our codebase come from internally-created code.

Requiring declare(strict_variables=1) to get this (better) behaviour punishes 
future users of PHP for our past mistakes.

> On Aug 28, 2019, at 12:05 PM, Thomas Bley  wrote:
> 
> Normally every code base has old and new code, some is actively maintained, 
> some is probably third-party maintained, some is unmaintained. Business 
> normally not calculates costs for upgrading, securing, GDPRing old code, so 
> bigger changes always leave some people behind.
> I would prefer to write new code with sth like declare(strict_variables=1); 
> or declare(SomeNamespace\Foo:strict_variables=1); That way, people can write 
> new code in a better way, include new libraries and upgrade old code piece by 
> piece without any big pressure.
> 
> Regards
> Thomas
> 
>> Matthew Brown  hat am 28. August 2019 um 17:32 
>> geschrieben:
>> 
>> 
>> It's essentially tech debt, and the language has allowed its users to
>> accrue a ton of it.
>> 
>> The longer that's allowed (deprecations/warnings prolong the issue in my
>> opinion) the harder it will be to fix the issues.
>> 
>>> On Wed, 28 Aug 2019 at 10:56, Rowan Collins  wrote:
>>> On 28 August 2019 15:22:22 BST, Matthew Brown 
>>> wrote:
>>>> Looking at our notice logs, I estimate (fairly roughly) that it would
>>>> require about a week's worth of my time to fix these issues
>>> I honestly thought you were posting that as an argument against. A week of
>>> resource (plus the accompanying QA impact etc) is a significant investment
>>> for many organisations. That's why it has the potential to delay adoption
>>> of a new version, and why a long lead-in via deprecation or opt-in is
>>> necessary.
>>> Regards,
>>> --
>>> Rowan Collins
>>> [IMSoP]
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>> 

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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

[Matthew Brown]

It's essentially tech debt, and the language has allowed its users to
accrue a ton of it.

The longer that's allowed (deprecations/warnings prolong the issue in my
opinion) the harder it will be to fix the issues.

On Wed, 28 Aug 2019 at 10:56, Rowan Collins  wrote:

> On 28 August 2019 15:22:22 BST, Matthew Brown 
> wrote:
> >Looking at our notice logs, I estimate (fairly roughly) that it would
> >require about a week's worth of my time to fix these issues
>
> I honestly thought you were posting that as an argument against. A week of
> resource (plus the accompanying QA impact etc) is a significant investment
> for many organisations. That's why it has the potential to delay adoption
> of a new version, and why a long lead-in via deprecation or opt-in is
> necessary.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>