Re: New RFC draft "static class constructor"

Am 13.04.2015 um 18:02 schrieb François Laupretre: >> 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. > Okay I will think about the alternative names, I somehow like __classInit you proposed or __classConstruct > - 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. On the one hand I think we should respect most of the user-land code as far as possible and on the other hand I think there should be the possibility to handle the being initialized or not initialized inside the class action. > > - 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. > Please see my answer 4 in discussion section for this: https://wiki.php.net/rfc/static_class_constructor#need_of_a_class_destructor_to_handle_unload_order_dependencies > Regards > > François > > -- DerOetzi