Re: [RFC] Factory for Stream Wrappers

Am 12.09.2011 00:26, schrieb Gustavo Lopes: > A patch against trunk (or 5.4) would have been nicer. Other than that: > * This patch has a huge BC: Johannes already said that he is updating his patch. It is not our intention to break BC, we only want to add additional/optional behaviour. > Could you add some examples substantiating these claims? I have some doubts. No matter how you implement the actual instantiation code in user land it should be obvious that you always have more control over it than having PHP do it for you in a "static" way. The usual case for a factory of course would be having an object instance where a method would be called - passing in array($obj, 'method') as the callback. But even a classic function has more control already, since it can decide which class to actually instantiate and what parameters it might need to set. Regarding state it is important to notice that PHP does *not* execute the constructor on all low level calls when instantiating the wrapper class - for whatever reason that is the case. Changing that behaviour would cause quite some side effects, with possible quite some BC breaks. > If, however, the factory is an object method, I see that you could change > state in the object and the factory method would have access to this new > state (and could inject in the wrapper object). Do you still need a use case for this? The main use case for Stefan and Arne was that we want to use a wrapper to map paths into protocols (e.g. have foo:// me mapped to $basedir . '/foo/') or define a memcached:// streamwrapper that obviously needs a server to talk to. This is usually a configuration that would be injected into the factory and from there be passed on to the instance. I do not have an example at hand that shows how this feature will help with testability, for that I am sorry. Maybe Benjamin can elaborate on what his use case is. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/