[Typo3-dev] extending extensions

[Michael Zedeler]

Hi there,

I posted something about the factory design pattern. It seems that we're 
already using it. Sorry.

More comments below.

Kasper Skårhøj wrote:

> I don't see that we are solving problems. if you want a warning that the same class is extended by more than one extension I think the EM could be made to do that.
> 
> BUT the main problem still is that we need to cascade the extensions automatically if this problem is to be solved.
> 
> I outline the problem here:
> 
> here two extensions (1 and 2) are both extending "Base Class":
> 
> EXT1
>   |
> BaseClass
> 
> 
> EXT2
>   | 
> BaseClass
> 
> 
> As it is right now ONE of them will win - the one loaded last in the extension repository.
> This means that 
> 
> EXT2
>   | 
> BaseClass
> 
> 
> ... is what we get (if EXT2 was loaded after EXT1)
> 
> 
> Now, what we really would like is to have something like this:
> 
> 
> EXT2
>   | 
> EXT1
>   |
> BaseClass
> 
> 
> This is only possible if EXT2 contains two setups namely:
> 
> 
> EXT2
>   | 
> EXT1
> 
> 
> and 
> 
> 
> EXT2
>   |
> BaseClass

 > [cut]

> This is now possible wit hthe adjustments to makeInstance that ingmar originally posted and I have implemented in 3.6.0.
> 
> BUT the problem still is that EXT2 must:
> - explicitly address compliance with EXT1
> - create and configure TWO identical extension classes, one for each scenario.

Now I think I understand the problem - what is wanted is an "arbitrary" 
stacking (or merging) of extending classes, right?

So if I have n different extensions to class A, they should all be 
loaded in some order that makes sense when I try to instantiate an object?

This venture is really dangerous. What about classes overriding each 
others methods?

If we're really, seriously talking about some sort of dynamic 
module-loading system, taht enables typo3 to load several different 
modules and merge them into one class, there should be some sort of 
namespace separation between the methods supplied from each module.

An example:

class module_1 {

   function method_a($somevar) {
     ...
   }
}


class module_2 {

   function method_a($somevar) {
     ...
   }
}

Merging the two modules above with useful semantics for calling the 
method method_a is really hard without some sort of inheritance 
hierarchy or just mandatory namespace separation. A mandatory namespace 
separation could be:

$this = <new instance>;
$this->module_2::method_a( ... );

Dependencies between modules can then be handled by some kind of 
instantiation method, where each module makes sure that other modules it 
depends on has already been loaded.

> This is not scalable really, before you know you have to explicitly address compliance with 5, 10 and soon hundred other extensions with the same number of redundant files.
> 
> In pseudo PHP code this is what could solve the problem:
> 
> class ux_
> 
> // Base class:
> class tslib_content {
> }
> // This sets a registy telling which class to instantiate if we need "tslib_content" - by default that is of course "tslib_content"
> $GLOBALS['classExtensionRegistry']['tslib_content'] = 'tslib_content';	
> 
> 
> // First extension:
> class myClassExtensionToTslibContent_1 extends $GLOBALS['classExtensionRegistry']['tslib_content'] {
> }
> // Now, the registry is changed because "myClassExtensionToTslibContent" is the class to extend and instantiate in case "tslib_content" is needed...
> $GLOBALS['classExtensionRegistry']['tslib_content'] = 'myClassExtensionToTslibContent_1';	
> 
> 
> 
> // Second extension:
> class myClassExtensionToTslibContent_2 extends $GLOBALS['classExtensionRegistry']['tslib_content'] {
> }
> $GLOBALS['classExtensionRegistry']['tslib_content'] = 'myClassExtensionToTslibContent_2';	
> 
> 
> // Third extension:
> class myClassExtensionToTslibContent_3 extends $GLOBALS['classExtensionRegistry']['tslib_content'] {
> }
> $GLOBALS['classExtensionRegistry']['tslib_content'] = 'myClassExtensionToTslibContent_3';	
> 
> 
> 
> 
> And getting an instance:
> 
> $object = new $GLOBALS['classExtensionRegistry']['tslib_content']
> 
> 
> ... giving us this class:
> 
> 
> myClassExtensionToTslibContent_3
>        |
> myClassExtensionToTslibContent_2
>        |
> myClassExtensionToTslibContent_1
>        |
> tslib_content
> 
> ... effectively letting all extensions affect the final instance.

Yes, but it opens up pandoras box with regard to methods overriding each 
other.

> This is what we want but cant get because PHP does not allow us to declare
> 
> class blablabla extends $someClassname {
> }

Thats because the construct above doesn't fit to any OO paradigm that I 
know of. You _have_ to know the API of the clas(ses) you extend. 
Otherwise it isn't really OO IMHO. Something that could solve the 
problem would be multiple inheritance, but it seems that the way PHP 
supports multiple inheritance results in something _very_ similar to the 
module-approach that I have sketched above.

http://dk2.php.net/language.oop

Regards,

Michael.