RFC: Sealed classes

1. Package

   1 4 0 0.0

   

   Kotlin: https://kotlinlang.org/docs/sealed-classes.html#location-of-direct-subclasses ( instead of using permits, all class within the same package are permitted, this won't work in PHP since we don't have pacakges, but if in the future we get packages, we can make it so that classes with no permit clauses are permitted to the same package - see https://github.com/Danack/Package/blob/master/rfc_words.md )

2. Stream

   getstream.io featured

   Stream - Scalable APIs for Chat, Feeds, Moderation, & Video. Stream helps developers build engaging apps that scale to millions with performant and flexible Chat, Feeds, Moderation, and Video APIs and SDKs powered by a global edge network and enterprise-grade infrastructure.

   

3. Symfony

   2 176 30,425 10.0 PHP

   The Symfony PHP framework

   

   One such example is FormTypeInterface in Symfony which has been changed few times. Because all the documentation said to use AbstractType, there has never been a problem for most.

4. z-engine

   3 4 452 0.0 PHP

   :zap: PHP Engine Direct API

   

   Operator overloading can technically be done in userspace via FFI with https://github.com/lisachenko/z-engine (I have an active PR adding headers for 7.4 and 8.1 as well as TS) - but it's super hacky and I would love to see it actually make it into PHP proper.

5. user-documentation

   4 3 131 6.9 Hack

   Documentation for those that use HHVM and write Hack code.

   

   I think there are thousands of other things to apply to PHP, rather than this, but if that's the way to go, well, the worse is nothing. Also just look at what https://docs.hhvm.com/ has and PHP doesn't, or go through LOLPHP.

6. PHP OAuth 2.0 Server

   5 10 6,604 8.9 PHP

   A spec compliant, secure by default PHP OAuth 2.0 Server

   

   I completely agree with this!! Sometimes there's too much hubris in OSS; classes made final, methods made private- because the author has made their mind up about how the library should work and be used. But sometimes it's not possible to imagine every use case. If software is extensible and someone breaks their app by extending your library and doing something wrong, that's their problem. Take a look at this for example: https://github.com/thephpleague/oauth2-server/issues/885 here the authors don't want to make it more extensible because some people might encode too many claims into their tokens and run into problems with header size. Ffs get off your high horse and let people use their own judgement !! /rant

7. http-message

   6 19 7,017 2.4 PHP

   The purpose of this PSR is to provide a set of common interfaces for HTTP messages as described in RFC 7230 and RFC 7231

   

   For instance look at https://github.com/php-fig/http-message/blob/master/src/RequestInterface.php . Implementers of that API need to read the detailed docblocks, not just the method names and signatures.

Suggest a related project