On Sun, Apr 25, 2021 at 11:36 AM Mike Schinkel <m...@newclarity.net> wrote:
> > > > On Apr 24, 2021, at 7:39 PM, David Gebler <davidgeb...@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 chasepee...@gmail.com
