Re: [RFC] Factory for Stream Wrappers

On Mon, Sep 12, 2011 at 16:56, Gustavo Lopes <glopes@nebm.ist.utl.pt> wrote: > Em Mon, 12 Sep 2011 15:40:20 +0100, Christian Kaps > <christian.kaps@mohiva.com> escreveu: > >> On Mon, 12 Sep 2011 14:43:33 +0100, Gustavo Lopes wrote: >>> >>> Em Mon, 12 Sep 2011 12:53:13 +0100, Sebastian Bergmann >>> <sebastian@php.net>  escreveu: >>> >>>>  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. >>> >>> This is a bit off-topic, but could you elaborate on this (possibly >>> submitting a bug report)? I see user_wrapper_opener trying to call the >>> constructor: >>> >>> >>> http://lxr.php.net/opengrok/xref/PHP_5_3/main/streams/userspace.c#298 >>> >>> So any failure to do this would be a bug. >>> >> >> Not sure if it's actual, but this behaviour is documented: >> >> http://de3.php.net/manual/en/streamwrapper.construct.php#94731 >> > > Ah, right. stat() and unlink() should have been static in the first place.. > > Given the circumstances, it might be a good idea, to document url_stat, > unlink, rename, mkdir and rmdir to be static and change the implementation > to: > > * not instantiate an object if the method is static > * keep the current behavior if it's not static (but emit E_STRICT) That seems like a change in behavior just to change it. Continuing on the off-topic notes.. I would rather go with an alternative implementation based upon interfaces (i.e. dirwrapper, filesystemwrapper, streamwrapper...) and spec it out before adding random magical things that took over 7 years for people to figure out and document. And lets not mention the stream_filter_register() and stream_bucket_new() voodoo. -Hannes