Re: OO Architecture redux

[email protected] (Tim Bunce) Wed, 5 Oct 2005 11:02:12 +0100
Newsgroups perl.dbi2.dev
Message-ID <[email protected]>
On Wed, Oct 05, 2005 at 01:34:15AM +0200, Jochen Wiedmann wrote:
> Tim Bunce wrote:
> 
> > - As an alternative to manipulating the internals of the handle,
> >   applications could compose new anonymous classes by mixing multiple
> >   roles.  Here's an extract from the roles docs url above:
> 
> I must admit that I have difficulties to understand the "roles" stuff. 
> For example:
> 
> >       $fido does Sentry does Tricks does TailChasing does Scratch;
> 
> Is it possible that TailChasing.chase invokes Sentry.chase? If so, then 
> I would think that this opens a lot of interesting options.

(As I understand it) roles can be composed into a class at compile time
or run time. At compile time multiple roles can be composed into a
single class and you'll get a compile time error if two roles define
the same method. When composing at run time each new role creates an
anonymous subclass. (You can probably do that at compile time as well.)

So, to answer your question, yes, TailChasing.chase would invoke
Sentry.chase if it did the equivalent of SUPER::chase (I think that's
NEXT in Perl6).

> >To HAVE-A handle or to BE-A handle, that is the question:
> 
> Considering the above, I do not think so. For example, it might look 
> like this:
> 
>   DBD::Base::Dbh   \
>                    $dbh   does   DBI::Dbh::Logger  does DBI::Dbh::This
>   DBD::Driver::Dbh /
> 
> DBD::Base::Dbh might be a class provided by the DBI, which the driver 
> handle does subclass. The various roles sitting in front of the actual 
> handle leave complete freedom to the DBI. However, the driver class is 
> still very simple (which was my original intention).

I'm not sure how that addresses the question of how someone creates a
class that subclasses the handle. But perhaps the point you're making is
that with roles that question may no longer be relevant. You may be right.

I think we need to get closer to implementation to be sure. Adopting the
'application handles are driver handles' approach as the default means
we'll be well placed explore this when we have some working code.

Tim.