Alban a écrit :
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.
Some language have support for IoC. See newspeak:
http://gbracha.blogspot.com/2009/07/ban-on-imports-continued.html
-- Mathieu Suen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
