Return-Path: mjd/plover.com Return-Path: Message-ID: <20011017005824.1876.qmail/plover.com> To: damian/conway.org cc: mjd/plover.com Subject: exported mixins Organization: Plover Systems Date: Tue, 16 Oct 2001 20:58:24 -0400 From: Mark-Jason Dominus I have a markup language processor called 'Mod'. There's an abstract Mod::Generic class, and Mod::Text, Mod::HTML, etc., which inherit from it. Sometimes the concrete classes need to fill text into justified paragraphs. I could put these methods into Mod::Generic. Instead, I put them into Mod::Fill. Mod::Fill exports its fill() and justify() methods into the calling package. Mod::Text then does "use Mod::Fill;" and gets these methods defined. I've never seen anyone else do this. It seems like a great idea. Can you think of any pitfalls? Thanks. Replied: Sat, 20 Oct 2001 12:35:52 -0400 Return-Path: damian/mail.csse.monash.edu.au Return-Path: Date: Sat, 20 Oct 2001 14:31:32 +1000 (EST) From: Damian Conway Message-Id: <200110200431.OAA37761@indy05.csse.monash.edu.au> To: Mark-Jason Dominus Subject: Re: exported mixins Reply-To: damian/conway.org Hi Mark, You asked: > Sometimes the concrete classes need to fill text into justified > paragraphs. I could put these methods into Mod::Generic. > > Instead, I put them into Mod::Fill. Mod::Fill exports its fill() and > justify() methods into the calling package. > > Mod::Text then does "use Mod::Fill;" and gets these methods defined. > > I've never seen anyone else do this. It seems like a great idea. That *is* unusual. It offers something like static inheritance semantics without otherwise overriding Perl's normal dynamic inheritance. I've not come across it before either. Nice. > Can you think of any pitfalls? Only that there is now no explicit IS-A relationship between Mod::Text and Mod::Fill. This might (very rarely) lead C astray. It's not a problem with a mixin class like Mod::Fill, though I'm not sure I'd want to use it for "real" base classes. Damian Return-Path: mjd/plover.com Return-Path: Message-ID: <20011020163552.14445.qmail/plover.com> To: damian/conway.org cc: Mark-Jason Dominus Subject: Re: exported mixins In-reply-to: Your message of "Sat, 20 Oct 2001 14:31:32 +1000." <200110200431.OAA37761@indy05.csse.monash.edu.au> Date: Sat, 20 Oct 2001 12:35:52 -0400 From: Mark-Jason Dominus > That *is* unusual. It offers something like static inheritance semantics > without otherwise overriding Perl's normal dynamic inheritance. I've not > come across it before either. Nice. > > > Can you think of any pitfalls? > > Only that there is now no explicit IS-A relationship between Mod::Text > and Mod::Fill. This might (very rarely) lead C astray. True. On the other hand, 'can' will still work correctly. I did think of a couple of advantages: If Mod::Fill contains auxiliary private functions, the normal inheritance mechanism will inerit them, even though you don't want that. With the export method, they stay private. There's a minor performance advantage since Perl won't have to search as far up the inheritance hierarchy to find the mixin methods. > It's not a problem with a mixin class like Mod::Fill, though I'm not > sure I'd want to use it for "real" base classes. I never thought of using it for real base classes. It seems like a poor idea but I'll have to think about it more carefully. But here's an alterantive ide in the other direction: Get rid of the runtime method lookup rules. Instead, make @ISA into a compile-time directive. If @A::ISA contains B, then at compile time, class B is searched for subroutines with the attribute 'method', and these are exported into class A and its subclasses, except where they would override methods already in those classes. This wouldn't be hard to implement. You would want to use @Isa instead of @ISA to avoid triggering the built-in inheritance semantics. ---------------------------------------------------------------- Replied: Wed, 24 Oct 2001 02:48:20 -0400 Return-Path: damian/mail.csse.monash.edu.au Return-Path: Date: Wed, 24 Oct 2001 16:42:30 +1000 (EST) From: Damian Conway Message-Id: <200110240642.QAA08892@indy05.csse.monash.edu.au> To: Mark-Jason Dominus Subject: Re: exported mixins Reply-To: damian/conway.org > here's an alterantive ide in the other direction: Get rid of the > runtime method lookup rules. Instead, make @ISA into a compile-time > directive. If @A::ISA contains B, then at compile time, class B is > searched for subroutines with the attribute 'method', and these are > exported into class A and its subclasses, except where they would > override methods already in those classes. Cute. I'd be happy to steal that if you don't get round to implementing it first ;-) Damian /home/mjd/bin/mailpager /home/mjd/MH-Mail/perl/conway/127 Return-Path: mjd/plover.com Return-Path: Message-ID: <20011024064820.11151.qmail/plover.com> To: damian/conway.org cc: Mark-Jason Dominus Subject: Re: exported mixins In-reply-to: Your message of "Wed, 24 Oct 2001 16:42:30 +1000." <200110240642.QAA08892@indy05.csse.monash.edu.au> Date: Wed, 24 Oct 2001 02:48:20 -0400 From: Mark-Jason Dominus > > here's an alterantive ide in the other direction: Get rid of the > > runtime method lookup rules. Instead, make @ISA into a compile-time > > directive. If @A::ISA contains B, then at compile time, class B is > > searched for subroutines with the attribute 'method', and these are > > exported into class A and its subclasses, except where they would > > override methods already in those classes. > > Cute. > > I'd be happy to steal that if you don't get round to implementing it first ;-) Please be my guest.