RE: [PHP-DEV] New RFC draft "static class constructor"
| From: | François Laupretre | Date: | Mon, 13 Apr 2015 16:02:21 +0000 |
| Subject: | RE: [PHP-DEV] New RFC draft "static class constructor" | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-85783@lists.php.net to get a copy of this message | ||
> De : Johannes Ott [mailto:mail@deroetzi.de]
> finally I managed to do my first RFC draft.
>
> https://wiki.php.net/rfc/static_class_constructor
>
> I hope I have done everything correct so far and I'm looking forward to
> your feedback on it.
Interesting. It also allows to respect PSR-1, which says 'Files SHOULD either declare symbols
(classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini
settings, etc.) but SHOULD NOT do both' (see https://github.com/flaupretre/automap/blob/develop/src/classes/Automap.php
for an example).
Comments :
- __static is ambiguous and does not reflect the method's role. Even if longer, I definitely
prefer __staticInit or, even better, __classInit.
- IMO, the method should be called when the class is created, just after every parent class and
implemented interfaces are created. If some load a bunch of classes they don't use, that's
their problem, not ours. It is not a reason to follow a two-step process. A properly written program
uses autoloading and loads the classes it needs only. Another argument is that I'm not sure it
is possible to catch every case of read access to static properties.
- I think you should provide a destructor method because there can be a need to cleanup/close the
resources opened when initializing the class. It can be open files, sockets, or any other resource,
but, IMO, they need to be explicitly closed when the request ends.
Regards
François