[RFC] [VOTE] Sealed Classes

3 years ago by Saif Eddin Gmati — view source

unread

Hello Internals,

As per my last email in the previous thread, i have started the vote for sealed classes feature.

The vote will run for 2 weeks until March 31st 2022.

Discussion: https://externals.io/message/117173

Draft Discussion: https://externals.io/message/114116

RFC: https://wiki.php.net/rfc/sealed_classes

Regards,

Saif Eddin.

3 years ago by Nicolas Grekas — view source

unread

Le jeu. 17 mars 2022 à 04:54, Saif Eddin Gmati azjezz@protonmail.com a
écrit :

Hello Internals,

As per my last email in the previous thread, i have started the vote for
sealed classes feature.

The vote will run for 2 weeks until March 31st 2022.

Discussion: https://externals.io/message/117173

Draft Discussion: https://externals.io/message/114116

RFC: https://wiki.php.net/rfc/sealed_classes

Hello Saif,

Thanks for the RFC.

I voted "no" because to me this closes extensibility in a hard way. If
users are fine ignoring an "@internal" annotation, or using reflection to
access private symbols, then I think that's fine: their problem; they know
why they need to do so - not authors. Allowing authors to forcibly remove
that capability from users is going too deep into removing power from users.

Said another way, I don't think this solves any problem that authors face
in practice. As such I don't think this is worth the added language
complexity + removal of power.

Cheers,
Nicolas

3 years ago by Saif Eddin Gmati — view source

unread

Le jeu. 17 mars 2022 à 04:54, Saif Eddin Gmati azjezz@protonmail.com a

écrit :

Hello Internals,

As per my last email in the previous thread, i have started the vote for

sealed classes feature.

The vote will run for 2 weeks until March 31st 2022.

Discussion: https://externals.io/message/117173

Draft Discussion: https://externals.io/message/114116

RFC: https://wiki.php.net/rfc/sealed_classes

Hello Saif,

Thanks for the RFC.

I voted "no" because to me this closes extensibility in a hard way. If

users are fine ignoring an "@internal" annotation, or using reflection to

access private symbols, then I think that's fine: their problem; they know

why they need to do so - not authors. Allowing authors to forcibly remove

that capability from users is going too deep into removing power from users.

Said another way, I don't think this solves any problem that authors face

in practice. As such I don't think this is worth the added language

complexity + removal of power.

Cheers,

Nicolas

Hello Nicolas,

to me this closes extensibility in a hard way.

This is not necessarily true, we have final in PHP which does exactly that, but sealed can still allow for extensibility, just from a different point, e.g:

sealed interface Option permits Some, None { }

interface Some extends Option {}
interface None extends Option {}

In this example, both Some and None are open for extension, but Option is closed for any type aside from Some and None.

I don't think this solves any problem that authors face
in practice

It does!

Considering the Option/Some/None example above, given Option, now you are sure that it's either an instance of Some or None, where previously, a third type could exist.

Authors previously got around this issue by adding methods on Option such as isSome()/isNone()/isSuccess()/isFailure() .. etc

reference: https://github.com/azjezz/psl/tree/2.0.x/src/Psl/Result

Having sealed classes, ensures that there can't be a third type at runtime, and makes the is*() methods absolute, as now you can check the instance type.

Regards,

Saif.

3 years ago by Nicolas Grekas — view source

unread

to me this closes extensibility in a hard way.

This is not necessarily true, we have final in PHP which does exactly
that, but sealed can still allow for extensibility, just from a different
point, e.g:

final has the same issue to me: it's a feature of the language that would
be better enforced by a static analyzer instead of a runtime check.

This would work for me:
#[Sealed(A::class, B::class, ...)]
interface Foo {...}
Then, nothing in php-core but a rule in SA tools to check that the
semantics of the attribute are respected (or a custom exception to the rule
when a user really wants to ignore the attribute for a specific class,
being on their own then).

Note that for final this is already common practice - using the @final
annotation to express the intent that a class is final but still allow e.g.
to generate a lazy proxy or a mock class (or any other need authors cannot
anticipate).

Considering the Option/Some/None example above, given Option, now
you are sure that it's either an instance of Some or None, where
previously, a third type could exist.

Authors previously got around this issue by adding methods on Option
such as isSome()/isNone()/isSuccess()/isFailure() .. etc

Or "instanceof Option|Some|None", which achieves something very similar to
me. This relates to the paragraph about composite types in the RFC: most of
the problems you describe for them can be solved in practice by introducing
an abstract (@internal) class.

Please note that I'm making these criticisms in a constructive mindset. I
do appreciate that there is an RFC about sealed classes and that we can
discuss if and how we want them in PHP. Right now, I'm not convinced we
should add them and I'm trying to articulate why, that's all :)

Nicolas

3 years ago by michal.brzuchalski@gmail.com — view source

unread

Hi Nocolas,

czw., 17 mar 2022 o 11:38 Nicolas Grekas nicolas.grekas+php@gmail.com
napisał(a):

Le jeu. 17 mars 2022 à 04:54, Saif Eddin Gmati azjezz@protonmail.com a
écrit :

Hello Internals,

As per my last email in the previous thread, i have started the vote for
sealed classes feature.

The vote will run for 2 weeks until March 31st 2022.

Discussion: https://externals.io/message/117173

Draft Discussion: https://externals.io/message/114116

RFC: https://wiki.php.net/rfc/sealed_classes

Hello Saif,

Thanks for the RFC.

I voted "no" because to me this closes extensibility in a hard way. If
users are fine ignoring an "@internal" annotation, or using reflection to
access private symbols, then I think that's fine: their problem; they know
why they need to do so - not authors. Allowing authors to forcibly remove
that capability from users is going too deep into removing power from
users.

Said another way, I don't think this solves any problem that authors face
in practice. As such I don't think this is worth the added language
complexity + removal of power.

I'd say this is a very weak argument, we do the same with the final on
class, method, property level already.
But well, it's your vote.

Cheers,
Michał Marcin Brzuchalski

3 years ago by Saif Eddin Gmati — view source

unread

Hello Internals,

As per my last email in the previous thread, i have started the vote for sealed classes feature.

The vote will run for 2 weeks until March 31st 2022.

Discussion: https://externals.io/message/117173

Draft Discussion: https://externals.io/message/114116

RFC: https://wiki.php.net/rfc/sealed_classes

Regards,
Saif Eddin.

Hello Internals
The vote for Sealed Classes RFC has been closed, and the feature was declined.
final vote: 16-11, which does meet the 2/3 minimum requirement.

Regards,
Saif Eddin.