[jifty-devel] Difference Between alias and import_templates in Template::Declare

Shawn M Moore sartak at bestpractical.com
Wed Oct 14 14:05:46 EDT 2009

On Tue, Oct 13, 2009 at 05:04:14PM -0700, David E. Wheeler wrote:
> On Oct 13, 2009, at 2:06 PM, Shawn M Moore wrote:
> > Perhaps mixin is the wrong metaphor for alias. I think delegation is a
> > better metaphor, since we really need the original class passed to the
> > aliased templates. See also
> > http://search.cpan.org/~drolsky/Moose-0.92/lib/Moose/Manual/Delegation.pod
> > for a definition of delegation and why it's good.
> Yes, delegation definitely better describes what it's doing, vis-a-vis  
> dispatch. I was using the mixin metaphor (and the `mix` method) based  
> on what I'd found in the docs so far.

The old TD docs.. let's just say it's probably okay if we burn them. :)

> > There's a place for the mixin metaphor, maybe that can be "import", or
> > something new.
> Well, `import` does something else in Perl. And it's not really an  
> import, either (which would be more like a mixin).

Yes, agreed. I'm saying that we could have another separate feature that
covers mixin/import.

> Honestly, though, I think `mix` is still the best work to use for the  
> feature because I can't think of a good way to make it happen with a  
> delegation metaphor. Delegation usually identifies all of the methods  
> to dispatch to when you specify it, as in:
>    use Class::Delegator
>        send => [qw(play pause rewind fast_forward shuffle)],
>          to => 'ipod';

The identification doesn't have to be done explicitly by the programmer.
For example, in Moose, we have:

has datetime => (
    is      => 'ro',
    isa     => 'DateTime',
    handles => qr/.*/,

In TD, we similarly select all templates.

> Which is not exactly how the TD feature works. What we're doing is  
> mixing templates from one class into another class. The fact that the  
> first argument is the mixed-in class rather than the target class is  
> something that's easy to document and understandable.

I'd rather not conflate the two.

Say we have a class C that mixes in a mixin M and has an attribute D. C
delegates some methods to D. The methods provided by mixin M will get C
as the invocant. The methods that are delegated to D will get D as the
invocant. There's a context switch involved with delegation that isn't
present with mixins.

The distinction is important. I'd really prefer to avoid clashing with
established models. If we get it right we can just say "oh if you use
this it's like a mixin, but if you use that it's like delegation." If we
get it wrong then users and experts alike will bang their heads against

Both forms of composition are useful and good. I think we can have
both in TD.

> Best,
> David


More information about the jifty-devel mailing list