On 16/06/2024 14:32, Mike Schinkel wrote:
Not supporting all features used in the wild would result in
developers not being able to use static classes for new and/or
refactored code if they believe they need those excluded features.
This would stop developers from signaling their intent to readers
of their code and would stop developers from being able to rely on
reflection to discern static classes for new and/or refactored
code when that otherwise could have been possible.
Disabling existing features just for static classes would result
in creating two forms of static classes — explicit and implicit —
and that IMO would be a miss for the addition of static classes.
You wrote the perfect words. Even if I do not agree with all of your six
conclusions following, I agree with this preface 100%, to such an extent
that I think it should form the underpinning basis for all further
decisions on this RFC and be enshrined in the preamble of said RFC, if
indeed I ever acquire such permissions as are necessary to actually
write it.
The idea of "implicit" versus "explicit" static classes is a clear and
powerful one that I think we can all understand, such that a successful
RFC would collapse this distinction; any failure to do so would
undermine the value of the feature entirely. As a concrete example,
then, prohibiting state in a static class is now completely off the
table simply because regular classes already support this feature.
Whilst some people have talked about idealogical aspirations for this
feature which sound valid in a vacuum, we must primarily concern
ourselves with the fact that this feature is being introduced into an
existing language, not a brand new language where such ideals would have
merit. And that is why this statement is so powerful: most (but perhaps
not all) of the answers to these disputed questions follow naturally
from the clear and guiding principle of this preface.
Thank you so much, Mike, for this! I feel confident I can write this RFC
now, and with help from Lanre, we already have the beginnings of an
implementation, too!
Cheers,
Bilge
