Le Thu, 19 Nov 2009 02:24:01 +0000, Jared Williams a écrit :
>> -----Original Message-----
>> From: Robert Lemke [mailto:rob...@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 s...@paradoxal.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
