On Fri, 19 Nov 2004 21:31:16 +0100, Marcus Ramberg wrote
> On 19. nov. 2004, at 19.47, Simon Flack wrote:
>
> > It would mean we could remove Maypole::Application. And I believe it
> > untangles
> > most of the multiple inheritance mess.
>
> Maypole::Application was meant as a way to select a driver easily,
I don't want to remove that functionality. I think it may be possible to clean
up Maypole's internals a bit so that Maypole::Application becomes redundant,
and you can just "use Maypole" in the same sort of way that you "use
Maypole::Application".
> Removing it won't change the fact that the way Maypole can be
> extended, for example to support authentication, is by multiple
> inhertiance. I'm not saying I support an architecture based on MI...
> But removing Maypole::Application will give you nothing with regarsd
> to this.
I don't believe I said it would. I think I said it might remove unnecessary
complexity and make it easier to test and maintain. It should be possible to
shift the functionality from Maypole::Application to Maypole if we make a
small change to the inheritance model...
Instead of:
MyApp --> Maypole::Application --> Apache::MVC --> Maypole
We could have something like:
MyApp --> Maypole <#>-- Apache::MVC
Key:
--> : inherits from
<#>-- : aggregates
There's only one level of inheritance in what I'm proposing.
Listen, right now, I'm just throwing some ideas around about how we might
improve Maypole's internals. I'm not proposing we change Maypole into
something else. Also these are simply ideas. I want to hear what people
think. 80% of what I say *may* be complete and utter rubbish. But rubbish is
as good a starting point for discussion as anything else.
I'm just trying to get the big picture here.
--simonflk
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT