Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55382
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 93.190.64.35 as permitted sender)
Message-ID: <4E6DF2A9.2040608@php.net>
Date: Mon, 12 Sep 2011 13:53:13 +0200
Reply-To: internals@lists.php.net
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: internals@lists.php.net
References: <4E6D0B5C.8030907@php.net> <op.v1n0lttyidpuyk@cataphract.cata.lo.geleia.net>
In-Reply-To: <op.v1n0lttyidpuyk@cataphract.cata.lo.geleia.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Factory for Stream Wrappers
From: sebastian@php.net (Sebastian Bergmann)

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/