Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:46096 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77714 invoked from network); 19 Nov 2009 03:45:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Nov 2009 03:45:47 -0000 X-Host-Fingerprint: 92.139.47.76 ANantes-552-1-72-76.w92-139.abo.wanadoo.fr Date: Wed, 18 Nov 2009 22:45:46 -0500 Received: from [92.139.47.76] ([92.139.47.76:21085] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 09/30-10882-96FB40B4 for ; Wed, 18 Nov 2009 22:45:46 -0500 Message-ID: <09.30.10882.96FB40B4@pb1.pair.com> To: internals@lists.php.net References: <20091119022332.GFJH21638.aamtaout02-winn.ispmail.ntl.com@p2> User-Agent: Pan/0.133 (House of Butterflies) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Posted-By: 92.139.47.76 Subject: Re: [PHP-DEV] RFC: Custom Factories (SPL) From: seza@paradoxal.org (Alban) Le Thu, 19 Nov 2009 02:24:01 +0000, Jared Williams a écrit : >> -----Original Message----- >> From: Robert Lemke [mailto:robert@typo3.org] Sent: 18 November 2009 >> 16:07 >> To: internals@lists.php.net >> Subject: [PHP-DEV] RFC: Custom Factories (SPL) >> >> Hi folks, >> >> after discussing the idea with various PHP developers I now felt safe >> enough that it's not a completely stupid idea to post an RFC for it. >> The idea is to add support the registration of custom factories which >> are responsible for instantiating certain classes. >> >> Here is the first draft of my RFC: >> http://wiki.php.net/rfc/customfactories >> >> I suggest that we first discuss the implications and usefulness of this >> feature. In a second step I'd need to find some skilled internals >> wizard who can implement it, because not being a C developer myself, >> all I can offer is making suggestions and fine coffee. >> >> Looking forward to hearing your comments! Robert >> >> -- >> Robert Lemke >> Fluent Code Artisan >> >> > Whilst I am a fan of IoC, I don't think its desirable to add language > features just to make legacy code more flexible. Surely the route to > take is to refactor the legacy code as and when the extra flexibility is > needed. > > Also seems like a possible whole heap of wtf?! When a seemingly absolute > statement $a = new A(); gets mangled behind the scenes. > > Jared I'm totaly agree with you Jared ! I'm a fan of IoC too. A factory can provide an object by creating an instance of a class, the choice of the class depends of some paramters. Those parameters can be provided directly by the programmer but also by a final user. PHP can not simply "choose" the class to instanciate by checking class's interfaces. What Robert Lemke wants to implement is called a "Service" or a "Container". You register a service and call the service instead of calling a class directly. Let me show it in an example of session registration : // you register the service Services::register('session', 'sessionStoredInCookie'); // and call it $session = Services::load('session'); Tomorrow, if you want change the session registration mechanism, for storing them in a database for exemple, you have just to change the registred service and whole application has change its session registration method : // you register the service Services::register('session', 'sessionStoredInDatabase'); This is very well treated by Fabien Potencier in this document : http:// fabien.potencier.org/talk/20/decouple-your-code-for-reusability-php- forum-2008?position=41 (some parts are in french) Implementing a service or container mechanism could be very simple or very complicated. Fabien Potencier use a very complicated example in the link above. Use a service or container mechanism (and its implementation) is a developper choice. this could not be traced by php core. A service (or container) can create an instance of class or just return an instance of class which is allready created. // you register the service Services::register('databaseConnexion', new databaseConnexionFactory ('mysql', array('server', 'database', 'user', 'password'))); // and call it $db = Services::load('databaseConnexion'); How PHP should treat the singleton ? getInstance() is just a convention. Create a service mechanism directly in php implies that php implements singleton model too. -- Alban Leroux seza@paradoxal.org