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

On Thu, 29 Apr 2021 at 09:14, Guilliam Xavier wrote: > > But so, when in a thread I receive a private reply that, for some reason > (e.g. somewhat rude but/or of public interest and maybe they clicked "Reply" > by inadvertance), I feel it should be forwarded to the list (which I have > seen

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

On Wed, Apr 28, 2021 at 10:18 PM Dan Ackroyd wrote: > On Wed, 28 Apr 2021 at 14:30, Guilliam Xavier > wrote: > > > > Forwarding to the list, and answering: > > > > Please don't do that. > > He was blocked from the list for repeatedly derailing conversations. > > After someone has been banned

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

On Wed, 28 Apr 2021 at 14:30, Guilliam Xavier wrote: > > Forwarding to the list, and answering: > Please don't do that. He was blocked from the list for repeatedly derailing conversations. After someone has been banned from the mailing list, forwarding their emails to the list is not a good

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

Re-forwarding to the list (please stop replying to me in private, thanks). Also re-answering but I will stop there because that's too much digression for a partial quote of my initial message. On Wed, Apr 28, 2021 at 5:30 PM Tony Marston wrote: > On 28/04/2021 14:30, Guilliam Xavier wrote: > >

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

On Wed, Apr 28, 2021, at 7:06 AM, Christian Schneider wrote: > Am 28.04.2021 um 01:00 schrieb Larry Garfield : > > However! Classic OOP design patterns are not all that PHP supports, and > > that's a good thing. The "class" construct, for better or worse, is the > > syntax for logic objects,

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

Forwarding to the list, and answering: On Wed, Apr 28, 2021 at 9:51 AM Tony Marston wrote: > On 27/04/2021 17:22, Guilliam Xavier wrote: > > On Sat, Apr 24, 2021 at 12:55 PM Saif Eddin Gmati > > > wrote: > > > > > > To me the first sentence of the RFC is debatable: > > > >> The purpose of

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

Am 28.04.2021 um 01:00 schrieb Larry Garfield : > However! Classic OOP design patterns are not all that PHP supports, and > that's a good thing. The "class" construct, for better or worse, is the > syntax for logic objects, value objects, data objects, and control flow > objects (such as

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

Le 28/04/2021 à 00:25, Christian Schneider a écrit : The same - "it is more liberty" - could be said about operator overloading, multiple inheritance and many other language features which lead to people using them in ways / places I consider harmful. So I'd rather not have them in my language

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

> On Apr 27, 2021, at 18:58, David Gebler wrote: > > Anyway, yeah - I've said my piece(s) and I'm not a voting member so what I > think doesn't matter to that end. I hope my input on internals discussions > is not entirely moot, though; just like everyone else I take part because > I'm very fond

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

Okay, I promise I'll make this my last word on the thread, for the sake of my own sanity and at this point, I'm sure that of others - first, I really appreciate your explanation there for why you consider this RFC a good thing, so thank you for that. Personally, my objections still stand for in

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

On Tue, Apr 27, 2021 at 7:00 PM Larry Garfield wrote: > On Tue, Apr 27, 2021, at 5:48 PM, David Gebler wrote: > > On Tue, Apr 27, 2021 at 11:23 PM Larry Garfield > > wrote: > > > > The two options to prevent such errors are: > > > > > > 1. Sealed classes. > > > 2. Extend Enums into ADTs. > > >

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

> On Apr 27, 2021, at 7:00 PM, Larry Garfield wrote: > > On Tue, Apr 27, 2021, at 5:48 PM, David Gebler wrote: >> On Tue, Apr 27, 2021 at 11:23 PM Larry Garfield >> wrote: >> >> The two options to prevent such errors are: >>> >>> 1. Sealed classes. >>> 2. Extend Enums into ADTs. >>> >>

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

On Tue, Apr 27, 2021, at 5:48 PM, David Gebler wrote: > On Tue, Apr 27, 2021 at 11:23 PM Larry Garfield > wrote: > > The two options to prevent such errors are: > > > > 1. Sealed classes. > > 2. Extend Enums into ADTs. > > > > Unless I've misunderstood your example, there is a third option

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

On Tue, Apr 27, 2021 at 11:23 PM Larry Garfield wrote: The two options to prevent such errors are: > > 1. Sealed classes. > 2. Extend Enums into ADTs. > Unless I've misunderstood your example, there is a third option which quite possibly prevents the error in a nicer, easier to reason about,

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

Am 27.04.2021 um 19:19 schrieb Pierre : > I think that the debate "but if your seal your classes I won't be to extend > it" is overrated: it's not the language to chose whether or not the > library/software author can seal its classes or not, it's up the > library/software author to do its own

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

On Tue, Apr 27, 2021, at 2:07 PM, Chase Peeler wrote: > > Sometimes it's helpful to apply a risk perspective the shed some light > > under hidden assumptions of different arguments. For example, what's > > the probability and impact of an event that would limit a coder when a > > library is using

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

On Tue, Apr 27, 2021 at 12:12 PM David Gebler wrote: > > > > On Tue, Apr 27, 2021 at 6:56 PM Levi Morrison > wrote: >> >> I think the conversation on final classes being "bad" has gone on long >> enough. You don't like final, and you don't want to see more features >> like it being added, such

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

> On Apr 27, 2021, at 3:07 PM, Chase Peeler wrote: > > As someone mentioned above, maybe they want to just add some logging > capabilities to maybe. > class MyMaybe extends Maybe { > protected $logger; > public function setLogger($logger){ $this->logger = $logger; } > public function

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

On Tue, Apr 27, 2021 at 2:57 PM Olle Härstedt wrote: > 2021-04-27 20:17 GMT+02:00, Chase Peeler : > > On Tue, Apr 27, 2021 at 1:56 PM Levi Morrison via internals < > > internals@lists.php.net> wrote: > > > >> I think the conversation on final classes being "bad" has gone on long > >> enough. You

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

2021-04-27 20:17 GMT+02:00, Chase Peeler : > On Tue, Apr 27, 2021 at 1:56 PM Levi Morrison via internals < > internals@lists.php.net> wrote: > >> I think the conversation on final classes being "bad" has gone on long >> enough. You don't like final, and you don't want to see more features >> like

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

Le 27/04/2021 à 19:51, David Gebler a écrit : I don't think at any moment that any of the people here really meant that, but it it's fundamentally what this argument does: it says that some conventions are by nature bad and the language should enforce people not to write code like this. I think

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

On Tue, Apr 27, 2021 at 1:56 PM Levi Morrison via internals < internals@lists.php.net> wrote: > I think the conversation on final classes being "bad" has gone on long > enough. You don't like final, and you don't want to see more features > like it being added, such as sealed. Point taken. Now

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

On Tue, Apr 27, 2021 at 6:56 PM Levi Morrison wrote: > I think the conversation on final classes being "bad" has gone on long > enough. You don't like final, and you don't want to see more features > like it being added, such as sealed. Point taken. Now please stop > dominating the discussion,

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

I think the conversation on final classes being "bad" has gone on long enough. You don't like final, and you don't want to see more features like it being added, such as sealed. Point taken. Now please stop dominating the discussion, thank you. -- PHP Internals - PHP Runtime Development Mailing

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

On Tue, Apr 27, 2021 at 6:19 PM Pierre wrote: > Le 27/04/2021 à 18:46, David Gebler a écrit : > > 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. > > It's

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

Le 27/04/2021 à 18:46, David Gebler a écrit : 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. It's not a functional change to the language, well, it is a new

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

On Tue, Apr 27, 2021 at 12:47 PM David Gebler wrote: > 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

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

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

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

On Sat, Apr 24, 2021 at 12:55 PM Saif Eddin Gmati wrote: > 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

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

Hi, On Mon, Apr 26, 2021 at 9:54 AM Christian Schneider wrote: > Am 25.04.2021 um 05:47 schrieb Larry Garfield : > ... > > 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

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

Le 27/04/2021 à 15:21, Dan Ackroyd a écrit : On Sat, 24 Apr 2021 at 15:03, Benjamin Eberlei wrote: 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

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

On Sat, 24 Apr 2021 at 15:03, Benjamin Eberlei wrote: > > 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. I think I disagree with this

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

Am 26.04.2021 um 14:18 schrieb Ilija Tovilo : > 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

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

Hi Christian On Mon, Apr 26, 2021 at 9:54 AM Christian Schneider wrote: > > Am 25.04.2021 um 05:47 schrieb Larry Garfield : > > 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

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

Yes I agree Chris, this is the same kind of argument I am making. > Note that the *exact* same argument could be made for typing parameters. I can document via a docblock that I expect a given parameter to be a string, or a Request object, or whatever. "There is little to no benefit in

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

Am 25.04.2021 um 05:47 schrieb Larry Garfield : > 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, >

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

2021-04-26 9:37 GMT+02:00, Pierre : > Le 26/04/2021 à 09:35, Olle Härstedt a écrit : >> 2021-04-26 9:22 GMT+02:00, Pierre : >>> Le 25/04/2021 à 21:22, Larry Garfield a écrit : Stitching together 2 replies to minimize thread noise... On Sun, Apr 25, 2021, at 11:58 AM, Michał Marcin

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

Le 26/04/2021 à 09:35, Olle Härstedt a écrit : 2021-04-26 9:22 GMT+02:00, Pierre : Le 25/04/2021 à 21:22, Larry Garfield a écrit : Stitching together 2 replies to minimize thread noise... On Sun, Apr 25, 2021, at 11:58 AM, Michał Marcin Brzuchalski wrote: Speaking of Attributes I prefer not

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

2021-04-26 9:22 GMT+02:00, Pierre : > Le 25/04/2021 à 21:22, Larry Garfield a écrit : >> Stitching together 2 replies to minimize thread noise... >> >> On Sun, Apr 25, 2021, at 11:58 AM, Michał Marcin Brzuchalski wrote: >> >>> Speaking of Attributes I prefer not to use an Attribute for any >>>

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

Le 25/04/2021 à 21:22, Larry Garfield a écrit : Stitching together 2 replies to minimize thread noise... On Sun, Apr 25, 2021, at 11:58 AM, Michał Marcin Brzuchalski wrote: Speaking of Attributes I prefer not to use an Attribute for any particular language feature which expects input

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

I did not expect nor intend to go down the rabbit hole regarding this topic, so this will likely be my last reply on this thread. > On Apr 25, 2021, at 4:51 PM, David Gebler wrote: > > On Sun, Apr 25, 2021 at 8:52 PM Mike Schinkel wrote: > >>> On Apr 25, 2021, at 1:52 PM, David Gebler

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

On Sun, Apr 25, 2021, at 3:51 PM, David Gebler wrote: > My argument is not that there aren't legitimate cases where you want to > indicate a class or interface as sealed, nor that developers should not be > empowered to make this indication. Right here is the core point. This is a subjective

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

On Sun, 25 Apr 2021 22:56:26 +0100 Chase Peeler wrote > On Sun, Apr 25, 2021 at 11:36 AM Mike Schinkel wrote: > > > > > > > > On Apr 24, 2021, at 7:39 PM, David Gebler wrote: > > > > > > I don't love this idea, I'm not very fond of the final keyword, either; > > >

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

On Sun, Apr 25, 2021 at 11:36 AM Mike Schinkel wrote: > > > > On Apr 24, 2021, at 7:39 PM, David Gebler 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

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

On Sun, Apr 25, 2021 at 8:52 PM Mike Schinkel wrote: > > On Apr 25, 2021, at 1:52 PM, David Gebler wrote: > > > > 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

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

> On Apr 25, 2021, at 1:52 PM, David Gebler wrote: > > 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

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

Stitching together 2 replies to minimize thread noise... On Sun, Apr 25, 2021, at 11:58 AM, Michał Marcin Brzuchalski wrote: > 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

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

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

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

On Sun, Apr 25, 2021, at 9:43 AM, Saif Eddin Gmati wrote: > On Sun, 25 Apr 2021 08:39:37 +0100 Olle Härstedt > 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 >

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

2021-04-25 18:27 GMT+02:00, Larry Garfield : > On Sun, Apr 25, 2021, at 2:04 AM, Olle Härstedt wrote: >> > 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

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

On Sun, Apr 25, 2021, at 2:04 AM, Olle Härstedt wrote: > > 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 > >

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

On Sun, Apr 25, 2021, at 9:48 AM, Mike Schinkel wrote: > > 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

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

> On Apr 24, 2021, at 7:39 PM, David Gebler 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

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

> personally I'm okay with using an attribute, but using a keyword for type > system related features seems like a better fit. > > > > I have added it to the alternative syntax list, which would have a separate > vote. > > > >

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

> On Apr 24, 2021, at 11:47 PM, Larry Garfield wrote: > > On Sat, Apr 24, 2021, at 2:55 PM, Olle Härstedt wrote: >> 2021-04-24 21:51 GMT+02:00, Marco Pivetta : >>> On Sat, Apr 24, 2021, 21:44 Olle Härstedt wrote: >>> 2021-04-24 17:59 GMT+02:00, Saif Eddin Gmati : >> Doesn't this

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

On Sun, 25 Apr 2021 08:39:37 +0100 Olle Härstedt 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

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

> 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

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

> For a more typical PHP example, getUser(int $id) is not a total function, > unless you have PHP_MAX_INT user objects defined in your database. If you > pass an int that does not correspond to a defined user, you now have to deal > with "user not found" error handling. getUser() is not a total

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

> 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

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

On Sat, Apr 24, 2021, at 2:55 PM, Olle Härstedt wrote: > 2021-04-24 21:51 GMT+02:00, Marco Pivetta : > > On Sat, Apr 24, 2021, 21:44 Olle Härstedt wrote: > > > >> 2021-04-24 17:59 GMT+02:00, Saif Eddin Gmati : > >> >> Doesn't this violate the principle: It should be possible to add new > >> >>

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

I don't love this idea, I'm not very fond of the final keyword, either; 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

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

Am 24.04.2021 um 21:51 schrieb Marco Pivetta : > On Sat, Apr 24, 2021, 21:44 Olle Härstedt > wrote: > >> 2021-04-24 17:59 GMT+02:00, Saif Eddin Gmati : Doesn't this violate the principle: It should be possible to add new features without touching old

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

2021-04-24 21:51 GMT+02:00, Marco Pivetta : > On Sat, Apr 24, 2021, 21:44 Olle Härstedt wrote: > >> 2021-04-24 17:59 GMT+02:00, Saif Eddin Gmati : >> >> Doesn't this violate the principle: It should be possible to add new >> >> features without touching old code? >> > >> > This depends on which

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

On Sat, Apr 24, 2021, 21:44 Olle Härstedt wrote: > 2021-04-24 17:59 GMT+02:00, Saif Eddin Gmati : > >> Doesn't this violate the principle: It should be possible to add new > >> features without touching old code? > > > > This depends on which syntax is picked, both `for` and attribute syntax >

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

2021-04-24 17:59 GMT+02:00, Saif Eddin Gmati : >> Doesn't this violate the principle: It should be possible to add new >> features without touching old code? > > This depends on which syntax is picked, both `for` and attribute syntax will > be completely BC. I'm not talking about BC, but the

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

Hi Saif On Sat, Apr 24, 2021 at 1:35 PM Saif Eddin Gmati wrote: > > 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

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

> Doesn't this violate the principle: It should be possible to add new features > without touching old code? This depends on which syntax is picked, both `for` and attribute syntax will be completely BC. using `sealed`+`permits` or `permits` only will result in these keywords being

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

2021-04-24 12:56 GMT, Pierre : > 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: >>

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

personally I'm okay with using an attribute, but using a keyword for type system related features seems like a better fit. I have added it to the alternative syntax list, which would have a separate vote. https://wiki.php.net/rfc/sealed_classes#syntax On Sat, 24 Apr 2021

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

> 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

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

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

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

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

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

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

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

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

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

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