[Typo3-dev] extending extensions

[Michael Zedeler]

Hi Christian,

Christian Jul Jensen wrote:

> On Fri, 16 Jan 2004 01:28:20 +0100
> Michael Zedeler <michael at zedeler.dk> wrote:
 >
>>I don't quite see the problem. Extending a class is done by simple 
>>inheritance. It must be instantiation that is the problem.
> 
> And that's how it works in TYPO3. But if two extensions extend and
> inherit form the same class ie. tslib_fe, it's not a trivial thing to
> determine whether these extensions can work together and in which order
> they should be instatiated if so.

Yes. Thats how I see the problem too. Look at some of my last postings 
in this thread...

 >>[cut]
>>It sounds like there is a problem deciding what class to instantiate
>>in a given context. This sort of problem is generally solved using the
>>
>>factory design pattern.
> 
> And this is actualluy the way it is implemented and why classes should
> be instantiated with t3lib_div::make_instance and not new. Because this
> function checks the TYPO3 environment to see if any extension extends
> the class that is about to be instantiated. As far as I see this
> approach doesn't solve the situation where two extensions claims to be
> the heir of a class.

Yep. I realized that a little later in the thread.

> The only thing I can imagine is a part of the extension manager that can
> detect a warn about such incompatibilities.

That would require explicit interface declarations unless you're ready 
to prove Turing wrong.

> If you have any suggestions on have this can be solved with class
> inheritance, they mostly welcome.

I don't think that ordinary class inheritance is the way to go, because 
the problem is that we want to use new methods implemented in several 
different classes with the same parent. I have worked on this problem 
for ages (since 1998) and the solution that I suggest is side-by-side 
modules that are isolated in private name spaces.

Trying to merge code together with a more or less fuzzy 
which-module-should-go-where algorithm is destined to be complicated for 
everybody to use and probably a real pain to maintain for the developers 
too.

See my message dated 16/1 in this thread for more details on the 
side-by-side solution.

This solution isn't very flexible, but I think that most of the things 
we want are in there, and it is very deterministic - no "funny" surprises.

Regards,

Michael.