[TYPO3-core] RFC #9505: Make the caches in TYPO3 use the new caching framework

Robert Lemke robert at typo3.org
Wed Oct 8 11:15:55 CEST 2008


Hi folks,

On 08.10.2008, at 09:08, Martin Kutschker wrote:

>> at least only one is needed, so I'd be fine with a singleton, too.  
>> But
>> to achieve this t3lib_div::makeInstance() must be made aware of  
>> singletons.
>> How about a simple check whether the class has a method named
>> getInstance(), if that is the case it is used instead of the new  
>> operator?
>
> I suggested this once, but Robert told me that singletons are bad when
> it comes to unit tests. I don't know, but maybe it helps (for unit
> tests) if t3lib_div::makeInstance() would test if the class  
> implements a
> certain (fake) interface or has a certain doc comment set and stores a
> reference to the object in a static variable.

yes, Singletons are bad. But we love Singletons!

Okay, more detailed:

In FLOW3 we have the concept of scopes: objects can be unique during  
one request,
during one session or they can exist multiple times. We call these  
scopes
"Singleton", "Prototype" and "Session".

The fact itself that an object follows the Singleton pattern, ie. its  
instance is
unique during one request, is _good_. In fact all objects in FLOW3 are  
of the
scope Singleton by default.

For TYPO3 v4 I propose the Registry / Service Locator pattern - and  
that's really
easy to implement:

The t3lib_div::makeInstance() function should become aware of scopes.  
In TYPO3 v4
the default scope should be "Prototype", because that's the current  
behaviour
of makeInstance(). If you want to make the solution upwards  
compatible, you'd have
to scan the doc comment of the class in question:

/**
  * My Class
  * @scope singleton
  */
class tx_myextension_myclass {}

That would be the cleanest solution in my opinion. However, you'll  
have to find out
if that turns out to be a problem speed-wise (due to Reflection). Just  
try it and
do some proper profiling with xdebug ...

As for the Registry part, makeInstance() should store all instances of  
classes
which are marked as "singleton". I strongly suggest to not store the  
instance in
the class itself and create a getInstance() method. That would really  
give some
headaches when it comes to unit testing because during the tests  
you'll want to
create a fresh instance for every test.

How the instances are stored by makeInstance() internally doesn't  
really matter
(static variable, global, ...). For testing purposes you'll probably  
want to
provide a service method such as setTestMode(boolean) which tells  
makeInstance()
to always return a fresh instance, regardless of the scope.

Anyway, how ever you implement it, please don't use the classic  
Singleton pattern
with a static getInstance() method.

BTW: I didn't check that, but ... did the unit tests somehow survive  
during the
backport of the cache framework?

Cheers,
robert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20081008/67b14e39/attachment.pgp 


More information about the TYPO3-team-core mailing list