[RFC][Draft] Sealed Classes

2021-04-25 18:27 GMT+02:00, Larry Garfield larry@garfieldtech.com:

A total function is a function that is defined over the entire domain of
its
inputs. For example, addition is a total function over integers,
because
for every possible pair of integers you pass to it there is a logical
return
value. However, square root is not a total function over integers
because
there are some integers you pass it for which there is not
representable
return value. (Negative numbers, unless you get into imaginary numbers
which PHP doesn't support.) In those cases, you have to throw an
exception
or return an error code or similar.

Maybe nitpicking, but PHP-land shouldn't make up their own
definitions: "A total function is a function that is defined for all
possible values of its input. That is, it terminates and returns a
value."
https://softwareengineering.stackexchange.com/questions/334874/in-the-context-of-functional-programming-what-are-total-functions-and-partia

Which means a total function is guaranteed to not have any errors,
like exceptions or division by zero. Compare with languages F* or Koka
which support this notation.

That... is literally what I said. There was no making up definitions. I
was using the actual mathematical definition. PHP is quite capable of
having total functions, they're a good thing, and we should try to encourage
them where feasible.

What's the point of encouraging total functions if you can't express
the totality in the type system?

Olle

---- On Sun, 25 Apr 2021 08:39:37 +0100 Olle Härstedt
olleharstedt@gmail.com wrote ----

In practice, I think all of the use cases for sealed classes are
ADT-esque.
As I noted before, combining sealed classes with Nikita's
new-in-expressions
RFC would allow for this (also using my short-functions RFC for
this
example, although that's a nice-to-have):

sealed class Maybe permits Some, None {

public const None = new None();

static public function Some($x) => new Some($x);

public function value() => throw new NotFoundException();

public function bind(callable $c) => static::None;
}

final class None extends Maybe {}

final class Some extends Maybe {
private $val;
private function __construct($x) { $this->val = $x; }

public function value() => $this->val;

public function bind(callable $c) => new static($c($this->val));
}

Yes, the Maybe/Option type is a good example! Because you know there
will never be another extension. But it's worth noting that whenever
you do not know that, these concepts suffer, even in functional
programming, by the same issues as I mentioned before with regard to
maintainability - you can't easily extend it without touching old
code
(there are attempts to fix this by making algebraic datatypes
extensible, but it didn't get widely adopted AFAIK). Also see this
thread about the expression problem:
https://stackoverflow.com/a/871375/2138090

Disregarding the limitations of maintainability, the real power of
algebraic datatypes is of course the pattern matching functionality
seen in OCaml and Haskell. I'm leaning towards tagged unions +
pattern
matching have more to offer PHP than sealed classes (and even more
so
when pattern matching can be extended with guard clauses and
catching
exceptions). The RFC author(s) might want to extend the RFC to
reflect
the relation to tagged unions, and how they overlap (or not)?

Olle

Pattern matching as it's currently being worked on would apply to arbitrary objects with visible properties, and enums are, in the engine, "just objects." So both a sealed class with public properties (or rather, properties visible in the scope) and an Enum with properties added (tagged unions/ADTs) would look the same to pattern matching. Naturally that RFC has to get finished first, but assuming it is, it would apply either way.

(Discrete but complementary components FTW.)

As mentioned in a previous email (
https://news-web.php.net/php.internals/114134 ), there's many
differences between ADTs and Sealed classes,
and in my opinion that's enough to have them both in the language as
personally i have use cases where ADTs won't work.

Many differences in terms of their implementation details, yes. Ilija lays out a good list of those in that email. However, they do address the same conceptual problem space.

Is there anything that ADTs or sealed classes would enable that the other one simply couldn't? If we can get a list of those, that can help us determine which is the ideal route to pursue or if there really is value in adding both despite their heavy overlap.

(The list of links you had before lacks enough context for me to figure out what you're suggesting, sorry. Please provide more precise comparisons of the two here.)

Also, another syntax suggestion:

final class Foo permits Bar, Baz {}

class Bar extends Foo {}

final already indicates that a class is inextensible. Sealed classes are poking holes in that guard. Essentially, final on its own is an extension cardinality of 0, sealed classes offer an exception list to that to give a precise cardinality list.

The main advantage here is that it introduces only a single new keyword, not multiple. If permits were replaced with for (as the RFC already offers), it would be no new keywords. Minimizing new keywords is generally a good idea anyway.

Am 26.04.2021 um 14:18 schrieb Ilija Tovilo tovilo.ilija@gmail.com:

The point of sealed type is to fix the number of subclasses a given
type can have, which means you can handle a value by type (as that
list is not finite). Code that handles Optional values could look like
this:

if ($option instanceof Option\None) {
   throw new Exception();
}

// We now know the value is a Some
var_dump($option->value);

I really hope that's not the way people will use the Maybe type....

If you suddenly provide your own version of None the code above will
break.

... but no, it wouldn't break, as MyNone extends None, so instanceof would still work.

To most people it's obvious that you can't add new cases to an
existing enum.

The RFC does not mention data classes (at least not explicitly), it talks about sharing common functionality.
So I think you're somewhat moving the goal posts.
If you want to limit Enums only then I would have to reconsider, but we were talking about generic classes AFAIK.

It doesn't sound sensible to add logging to a data
class. That's something that belongs into a hook or service of some
kind.

You're again making assumption about what's sensible for the user of a library, that's the mind-set I would like to avoid.

People might also want to use sealed for behavioral classes, the use
case here is the same as final. Final is not here to make your life
harder. It's here to make the lives of the library maintainers easier.

First of all: Yes, I'm no fan of final either.
I've encountered enough examples where it did make my life harder.
And as a library writer myself I value the user experience higher than the library developer work because there are (hopefully) a lot more users than developers.

If they have to reason about every way a method could be overridden,
every change in the library would become more risky, require more
thought and more frequent major version updates.

A properly designed API should be simple and stable enough to not need this kind of safe-guards.
Overly complicated, cathedral-style frameworks might yearn for it but I think it's addressing the symptoms, not the cause (-:C

This means more work and less features for you, too.

That kind of argument reminds me of people saying that user tracking is a good thing because I get to see more relevant advertisement.
You're a good sales-man though, I give you that, but you haven't convinced me yet ;-)

• Chris

Still, it remains that one could have a legitimate, justifiable reason to
extend Maybe / some other example, which was not foreseen by its author and
is prevented by sealed as a keyword despite the fact this inheritance,
correctly implemented, would not break anything, not define an impossible
state and not violate anything except the library author's own (limited)
imagination of how their code ought to be used.

Note in respect of the point people have raised about attributes and my own
previous comments, I am not advocating any Sealed attribute is added to the
language as a functional change or embedded language by the backdoor, I am
merely saying you as some class's author can add an attribute, right now,
to indicate that you consider the class sealed - and an IDE / automated
tooling could understand it and warn a user there is a risk to violating
it.

What's being proposed in the RFC is a functional change to the language
whereby attempting to extend a class designated as sealed to a
non-specified child results in a fatal error.

Now that is not a benefit in itself, it is merely a description of the
proposed change. My question is who or what benefits from this change? And
I look at this way:

1. The language engine doesn't benefit, since unlike some compiled
   languages, there is no indication here it will result in improved opcode
   sequences.

2. The author of code doesn't benefit, to any extent greater than they
   would by using an attribute or other metadata to indicate their intentions,
   because if someone else comes along, installs their library and creates
   problems for themselves by extending some concrete type in a manner which
   was not intended, the author's obligation to them is zero. If improperly
   inheriting or otherwise misusing code creates a problem for a consumer,
   it's the consumer's mess to sort out.

3. The consumer of code doesn't benefit, because if they didn't intend to
   inherit from a sealed, concrete class, it being sealed makes no difference.
   But if they did - and had a legitimate reason to do so - they are now
   forced to fork, proxy or otherwise work around this artificial restriction
   (which they can easily do, by the way, language keyword or none). In any
   valid use case, this can distinctly and only be a disadvantage to them.

Someone - Larry I think - said something to the effect of this isn't about
restricting your users as an author from doing something you think they
shouldn't, and that it's about more completely defining problem spaces at
language level. I respectfully am not convinced. When we look at features
like enums and stronger typing, we can see distinct benefits in how as
users of PHP we can model better and write better, more effective and more
efficient code.

But in the case of sealed and the context of PHP, you cannot model your
problem space this way better than you can with an attribute or other means
of annotating metadata. I can certainly agree such metadata is an important
part and valuable tool for improved modeling, but making it a keyword and
throwing a fatal error if your limited intentions (which do not predict all
possible use cases) are violated is merely constraining users from being
able to do something for its own sake. While there is a legitimate argument
that serves to "syntactically make certain invalid states impossible", it
does the same for any valid states you didn't envision.

I'm maybe even inclined to suggest the desire to make a class sealed really
smells like you want to be using abstract classes and/or interfaces.

To the greatest extent which is practical, my preference is to enable other
developers rather than constrain them (subject to the caveat I will not
help them if they do something silly or irresponsible with my code on their
own volition) - I don't believe the "weirdness" exceptions PHP makes
internally for things like Throwable or Traversable are good reasons to
extend this to the language level.

On Tue, 27 Apr 2021, 16:05 Guilliam Xavier, guilliam.xavier@gmail.com
wrote:

Hi,

On Mon, Apr 26, 2021 at 9:54 AM Christian Schneider <cschneid@cschneid.com

wrote:

Am 25.04.2021 um 05:47 schrieb Larry Garfield larry@garfieldtech.com:
...

sealed class Maybe permits Some, None {
...
}

final class None extends Maybe {}

This is exactly the thing I'm worried about.

Say I want to add something like logging to the None type.
Now your sealed and final classes prevent me from defining MyNone
extending None even though it would be 100% compatible with None.

I just want to note that this has nothing to do with Maybe made sealed
(which seems legit), only with None made final (which... could be debated,
but unrelated to the RFC at hand).

Regards,

--
Guilliam Xavier

Stitching together 2 replies to minimize thread noise...

Speaking of Attributes I prefer not to use an Attribute for any particular
language feature which expects input arguments to be a valid class or
interface name for two reasons: first because there is no effective way to
restrict input string to be a valid class or interface name and second that
it'd require passing strings which means in most cases passing class or
interface name with magic ::class constant read.

Cheers,
Michał Marcin Brzuchalski

That's actually a pretty solid argument against attributes here, honestly. Consider me convinced, and now in favor of "final class Foo permits Bar, Baz". :-)

Still, all these problems are solved to the same degree if you add a
#[Sealed] attribute to a class which has no functional impact. You have
sufficiently indicated to any user that extending this class is not a
designed feature and may cause backwards-incompatible breaks with future
releases - in a way that both a programmer and IDE can reason about, which
in PHP's context is what matters. Attributes arguably even have a greater
qualitative advantage that they can be applied right down as far as
individual method parameters.

In Java the idea of final and sealed classes makes more sense, since we
actually to some extent need the compiler to be able to reason about these
types and can gain optimization and code generation benefits from its being
able to do so. PHP's concept of typing and implementation of type checking
as an interpreted language is completely different.

I wonder, if final and sealed as language constructs really offer the
guarantees about intent and safety their advocates say they do, why are
they not the default? Why can no one point me to a language where I have to
write something like

extendable class Foo permits all { .... }

(and there are people who would be in favour of making inheritability this
explicit, but I'm not one of them)

It's one thing as an author of code to say "I only intended and support
this finite set of use-cases", it's quite another to say "and you should be
impeded from proceeding with any legitimate use-case I didn't imagine or
foresee"

In practice, the only thing I've ever seen this achieve is to create
difficulties, while the claimed benefits can be adequately (and better)
achieved through existing patterns like annotations, interfaces and DI.

Part of the challenge here, i think, is that PHP, like most classic OOP languages, uses the same syntax for two different things. One is for product types (an int combined with a string together in a single struct), the other is bound values in closures (aka, methods in service objects). That's arguably by design in classic OOP, and arguably a design flow in classic OOP. :-)

I can think of no reason at all to make a service object's class sealed. For those, yes, you shouldn't forbid custom extension, and frankly I usually discourage the use of private variables, too, for the same reason.

For product types that are part of the domain, however, there are definitely use cases where you want a defined finite list of possible variants. The Distance and Maybe examples upthread, for instance. That's not always the case, but there are definitely cases for them.

--Larry Garfield

Still, all these problems are solved to the same degree if you add a
#[Sealed] attribute to a class which has no functional impact. You have
sufficiently indicated to any user that extending this class is not a
designed feature and may cause backwards-incompatible breaks with future
releases - in a way that both a programmer and IDE can reason about, which
in PHP's context is what matters. Attributes arguably even have a greater
qualitative advantage that they can be applied right down as far as
individual method parameters.

In my experience, if a developer needs access to a feature that is easily available via the use of a method that is merely documented as internal-use only, the developer will use it rather anyway than spend a lot more time trying to work around what that method makes easily available. Especially if that documented internal-use only is about not subclassing.

And if many other developers do that, the original developer will still have the same problem as if they didn't document it as internal-use only.

But I do acknowledge your experience might be different. FWIW.

In Java the idea of final and sealed classes makes more sense, since we
actually to some extent need the compiler to be able to reason about these
types and can gain optimization and code generation benefits from its being
able to do so. PHP's concept of typing and implementation of type checking
as an interpreted language is completely different.

I wonder, if final and sealed as language constructs really offer the
guarantees about intent and safety their advocates say they do, why are
they not the default? Why can no one point me to a language where I have to
write something like

extendable class Foo permits all { .... }

(and there are people who would be in favour of making inheritability this
explicit, but I'm not one of them)

Well, I can't point you to a language that works that way because I don't know more than a handful of languages in depth — although there may be one — but I can point you to a language that does not even allow you to subclass: Go.

The Go designers wanted to get away from the fragile base class problem so they provided embedding instead:

https://medium.com/@simplyianm/why-gos-structs-are-superior-to-class-based-inheritance-b661ba897c67

I program more in Go now than in PHP, and I can confirm that its approach works brilliantly. Better IMO than what PHP currently offers in that respect.

It's one thing as an author of code to say "I only intended and support
this finite set of use-cases", it's quite another to say "and you should be
impeded from proceeding with any legitimate use-case I didn't imagine or
foresee"

I do respect that as a user of other developer's code you might view it that way.

But then I also can respect the library or framework developer who chooses to make their own job less difficult by (wanting to) mark a class to be sealed.

You claim "it's quite another thing to say" but I don't think a developer of library or framework code should be required to offer features to their users they do not want to offer. It is the developer's prerogative; if they want to be able to mark their classes as sealed they should be empowered to do so. IMHO, anyway.

In practice, the only thing I've ever seen this achieve is to create
difficulties, while the claimed benefits can be adequately (and better)
achieved through existing patterns like annotations, interfaces and DI.

I would argue that maybe the reason you have only seen it create difficulties is because of your own perspective and experiences that are, by definition, anecdotal and thus limited.

OTOH Fabien Potencier and/or Taylor Otwell might have a different experiences and thus a different perspective on what those benefits are (but I am admittedly just hypothesizing here.)

-Mike

---- On Sun, 25 Apr 2021 22:56:26 +0100 Chase Peeler chasepeeler@gmail.com wrote ----

On Sun, Apr 25, 2021 at 11:36 AM Mike Schinkel mike@newclarity.net wrote:

On Apr 24, 2021, at 7:39 PM, David Gebler davidgebler@gmail.com wrote:

I don't love this idea, I'm not very fond of the final keyword, either;

I'll start by saying the final keyword caused me a tremendous amount of
heartache because it was used on a class in a framework that I badly, badly
needed to extend.

But even so, I recognize why they used it, and I still don't have a great
argument for how they could address the reasons they used it some other way.

I've always believed annotations (or attributes in PHP these days) are a
better of way of indicating you, as an author of a class, did not write
it
with inheritability in mind or intended than restricting language
features
through syntactic constructs.

The RFC says "when you have a class in your code base that shares some
implementation detail between 2 or more other objects, your only
protection
against others making use of this class is to add @internal annotation,
which doesn't offer any runtime guarantee that no one is extending this
object", to which I ask - why do you need this guarantee? What does it
qualitatively add? If I make a judgement that I want to extend your class
or implement your interface, I can just delete the sealed keyword from
your
code and carry on. So it doesn't actually offer any guarantee at all that
I'm not extending the type.

Actually, it does offer such a guarantee. It guarantees if you are using
a non-forked version of the original developer's (OD's) library or
framework then that class won't be extended. When someone pulls the
original non-forked version from its source repository — such as when using
Composer — then that code will be (effectively) guaranteed not to be
extended.

OTOH, if you do delete the sealed (or final) keyword you have then forked
the code, in a defacto manner if not a literal one. If you use a forked
version of the code, you now own the maintenance of that code and any bugs
that are generated by your forked changes in using code. The original
developer has no moral, ethical or even contractual obligation to care
about the breakage you cause.

I'd argue that if the original developer made clear that you shouldn't
extend a class, then they still have no moral, ethical, or even contractual
obligation to care about the fact you've used the object in a way they were
clear was not supported.

I'm with David on this one. I can understand the need to enforce a
final/sealed concept for core functionality implemented in C which might do
some funny things under the hood. I don't think that should be extended to
userland. If you want to warn someone, that's fine. But don't totally
prohibit them.

Given the ability for composer to pull from forked repos and the easy of
keeping a forked repo in sync with it's upstream version, creating a fork
just to remove a sealed/final designation isn't that difficult to do.

Hypothetical example: You fork the code, remove sealed/final, then
subclass the code and add a method, let's call it ToString(). And you write
your application to use ToString(). Now the OD releases a new minor version
and they also add a ToString() method. Applications using your fork
probably cannot use the new version of the OD's library because when the
library calls ToString() your version is called. So you have to update your
application to use the new version of the library and once again remove
sealed/final.

AND, if your code is instead another add-on library, now users of your
add-on library will also have to fix their code too. Which could
potentially be a large number of users if your add-on is successful.

So not using final or sealed can result in some really hairy and possibly
impossible to fully resolve backward compatibility concerns for developers
who publish libraries and/or frameworks.

The best it can achieve is to indicate your
intentions, which I believe can be adequately done today through an
attribute, no addition to the language needed.

Still, I concur with your concerns. Developers too often implement final
classes in libraries and frameworks without fully addressing all the
use-cases and/or adding enough extensibility points because it makes their
lives easier. Because of that final — and sealed, if added — can make the
life of an application developer a living hell.

So what's the answer? I don't know that I have the ultimate answer, but I
would be a lot more comfortable with adding features to PHP such as ones
like sealed that restrict the "O" in S.O.L.I.D.[0] if PHP were to offer the
following three (3) things, all of which can be found in Go, and I am sure
other languages:

1. Class embedding[1] — Allows one class to embed another and immediately
   have access to all its properties and methods, and also to be able to
   extract an instance of that embedded class. It is called "Type embedding"
   in Go.

2.Type definitions[2] — A typedef would allow developers to define
constrained versions of existing types, such as FiveStarRating which
could only contain 1, 2, 3, 4 or 5, or types that identify a signature, for
example as ConvertToString which could require a closure that implements
func(mixed):string. In Go you can compose other types to create new
types, but I'm not sure if those other type of types could apply to PHP, at
least as it currently exists, and especially because it is not a compiled
language.

3. Structural typing[3] — Basically interfaces that can be implemented
   implicitly rather than explicitly. For example, if I wanted to implement a
   Stringable interface that requires a ToString():string method then
   structural typing would allow me to implement that interface simply by
   adding a ToString() method instead of requiring me to also add "implements
   Stringable" to the class definition.

Those three features are all killer language features and would make great
additions to PHP. IMO, of course.

#fwiw

-Mike

[0] https://stackify.com/solid-design-open-closed-principle/
[1] https://travix.io/type-embedding-in-go-ba40dd4264df
[2] https://go101.org/article/type-system-overview.html
[3]
https://blog.carbonfive.com/structural-typing-compile-time-duck-typing/ <
https://blog.carbonfive.com/structural-typing-compile-time-duck-typing/>;

--
Chase Peeler
chasepeeler@gmail.com

I can understand the need to enforce a final/sealed concept for core functionality implemented in C which might do some funny things under the hood. I don't think that should be extended to userland. If you want to warn someone, that's fine. But don't totally prohibit them.

This is not about doing "funny things under the hood", this is about declare a possible sub-types for a specific type.

Taking the ResultInterface example from the RFC, there can only be 2 sub types for it, Success or Failure, so when a function declares it's return type as ResultInterface, you know you are getting either one of these two data types, any nothing else.

If the interface would be unsealed, that guarantee doesn't exist anymore, and the library which might contain functions that operate on the Result type would become broken as now they have another type that is not being handled when unwrapping ( hence why Psl doesn't actually contain the unwrap function mentioned in the RFC ).

given the ability for composer to pull from forked repos and the easy of keeping a forked repo in sync with it's upstream version, creating a fork just to remove a sealed/final designation isn't that difficult to do.

Yes, you can, but i don't think any maintainer is willing to waste their time looking into a weird bug resulted from new types that you created by unsealing a sealed class/interface.

If you ever had to do this, then the library you are using is flawed, as it should offer you a way to extend things when inheritance makes sense, but sometimes it doesn't ( e.g there's no reason why someone would want a new Result type that is not Success or Failure, or would want to implement the ExceptionInterface that is used within a library )

for services, I prefer to have implementations declared final, but also offer an unsealed interface to make it possible for people to decorate the implementation or rewrite their own.

If you find yourself in need to extend a class that is declared final, decorate it instead, and if there's no interface for it, maybe send a PR, forking to remove final is not the solution.