[Typo3-dev] no strict inheritance; was: extending extensions

[Marc Schlienger]

Hi,

I'm following this discussion with interest, but I'm not sure if I really
get the grasp of your problem with "extending extensions". Actually, it seems
to me that strictly using inheritance is not the way to go here. Maybe someone
could explain me what, in the end, is desired?

Let's take the role of the extension repository (ER).  Apart from managing
extensions, the ER might be used to instantiate them, to apply extension based
funtionality on something, to process data through its extensions. So here,
we see a clear need for a defined API:
- say, an interface that describes what an extension does (this can be seen
as the base extension class, if we would be speaking about inheritance). Each
extension will implement this interface.
- an interface for the ER that clearly defines the places where the
functionality can be extended. When loading an extension, you can say at which place
it should be inserted in the processing chain. If two extensions claim to
achieve the same goal, you can deactivate the duplicated one.

Let's take the extension developer point of view. When you develop an
extension, you do not know which are the other ones (being developed), you might
find that some part of the base extension is inappropriate, or you might not
have access to the base class functionality. So here inheritance is not the
solution. Inheritance is a way to extend the behaviour of a defined base class,
but in one direction, that is, in the direction of the inheritance tree (From
top to bottom).

Following this discussion, I have understood that you need a plugable
behaviour. Each extensions might add its own stuff to the whole processing. So
please, tell me if I see it wrong here, but I would suggest using some
combination of:
1) Mock Objects
2) Pipes and Filters


To 1) Mock Objects: change the behaviour of your "base class" using
interface replacement, not inheritance. This is also know as the Visitor Pattern. 
Example:

class VisitedClass {
   member:  data (Type: something)

   method doSomethingOnData( VisitorInterface c ) {
      Iterator it = data.getIterator();
      
      while( it.hasNext() ) {
         foo = it.next();
         result = c.apply( foo );
         # do something with foo
      }
   }
}


class SomeVisitorClass extends VisitorInterface {
   method apply( Something data ) {
      print( data.getMember() + " is being visited by me and I'm potentially
modifying it" );
   }
}

this could be used in the ER to let extensions provide take some "political"
decisions, to modify the order into which things get loaded, etc.



To 2) Pipes and Filters: typically, when dealing with data processing, you
want to chain the processing in a custom way. The pipe drains the data that is
progressively worked out by Filter 1, Filter 2, ..., Filter n. The amount of
filters is open, their order too. Example:

some Extensions can be seen as Filters. They are on the html process stream
and perform some operations, say:
- one filter produces the content
- second filter integrates the layout
- third filter checks user permissions
- etc.

Well, this is quite fuzzy here, but it might give you some ideas...

Regards,

Marc


> On Fri, 16 Jan 2004 01:28:20 +0100
> Michael Zedeler <michael at zedeler.dk> wrote:
> 
> > Boris Nicolai wrote:
> > 
> > > morning,
> > > I run into serious trouble as I want to develop another ext which
> > > extends the tslib_fe.
> > > the problem is as already sometimes discussed, what if I want to
> > > install two ext that extend tslib_fe (or whichever class)?
> > 
> > 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.
> 
> > > so I thought a bit and maybe I got a solution without the time to
> > > develop it:(
> > > A basic-class could look if there are classes that extend this
> > > class. if so, the basic-class creates an instance of this XCLASS,
> > > and if a function of the basic-class is called then the basic-class
> > > checks if this function doesn't exist in one of its
> > > extension-classes.  [...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.
> 
> The only thing I can imagine is a part of the extension manager that can
> detect a warn about such incompatibilities.
> 
> If you have any suggestions on have this can be solved with class
> inheritance, they mostly welcome.
> 
> -- 
> ./mvh Christian Jul Jensen
>       Freelance webprogrammer
>       TYPO3 Typehead Denmark
> _______________________________________________
> Typo3-dev mailing list
> Typo3-dev at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev
> 

-- 
+++ GMX - die erste Adresse für Mail, Message, More +++
Bis 31.1.: TopMail + Digicam für nur 29 EUR http://www.gmx.net/topmail