[Templates] Meet the Badger (TT3's half-cousin) Redux

Stevan Little stevan.little at iinteractive.com
Tue Sep 9 16:54:21 BST 2008


Andy,

On Sep 9, 2008, at 8:59 AM, Andy Wardley wrote:
> Hi Stevan,
>
> Thanks for taking the time to set me straight. I apologise for  
> making such a
> bad job of comparing the two. I can assure you that it was only my own
> ignorance at fault and no malice was intended. I hope I didn't  
> cause any
> offense.

No offense taken at all.

>> As for the clever magic, you will find very little of it inside
>
> Ah, but the emphasis was on *clever* rather than magic.  :-)
>
> And there's some *really* clever stuff in Moose (and Class::MOP).  
> It is magic,
> in the sense that it happens behind the scenes, but it's definitely  
> good
> magic. Not to be confused with...
>
>> Deep magic in Perl is almost always fragile
>
> Agreed.   <shudder>

Yeah, fair nuff, I agree with you on that point. I guess there is  
also different notions of magic for different people. Hanging around  
Audrey in the Pugs days, and Yuval Kogman and Matt Trout these days,  
what I consider deep magic tends to be really deeply totally batshit  
insane magic to others.

>> Moose too uses the "regular" Perl 5 object model, don't be fooled  
>> by  the nice syntactic sugar, it is only sugar, underneath it all  
>> Moose  is just plain old vanilla Perl 5 hash-based OO.
>
> Yes, totally understood.  I think what I was trying to get at was the
> different syntactic style of creating object classes and how closely
> that maps onto to the underlying old school Perl 5 implementation  
> (or not).

Yup, agreed, that makes sense.

> (BTW I just found Moose::Unsweetened which is very useful here)

Yup, Dave Rolsky++ for that one, he has done an amazing job on the  
docs :)

> Badger's evolution has been much more closely aligned with the old  
> school Perl
> 5 object model, as an accident of history rather than design  
> (Badger is mostly
> re-churned code from the last 10 years rather than a new design  
> from scratch).
> As a result, I think there's less of a mental leap than that  
> required to leave
> the old school Perl 5 rules behind and start thinking in terms of  
> new school
> Moose.

Yes, this is true, and I have found it more and more as people have  
tried converting Class::Accessor code to Moose. THere are some  
Class::Accessor-isms which just don't work with Moose (the permissive  
C::A constructor is one, and use of undef in the C::A accessors).

> Moose operates at a slightly higher level of abstraction. To  
> stretch the
> analogy, it's like jumping in a taxi and letting the taxi driver  
> find the best
> route. In contrast, Badger gives you a bike (it's got a basket, a  
> bell that
> rings, and things to make it look good) and a map of some nice  
> forest trails
> with good foraging spots along the way.

Great, now that that song is in my head its gonna be another Early  
Floyd/Syd Barrett day in the old iTunes.. helloooo crazy!

But yeah I think your analogy is correct, Moose does try and do a lot  
for you in comparison to Badger, both exposing the control of these  
things in a different way. However I think your undercutting Badger a  
bit, I think that along with a Bike and a map of forest trails, it  
has also packed a picnic lunch, some energy bars, a snake bite kit  
and small tent in case you find a nice place to camp.

>>>     * Moose is more framework, Badger is more toolkit.
>> Actually I disagree here, a Framework is typically something which  
>> is  partially complete, but needs your code to fill in the rest in  
>> order  to become a full application. Catalyst is a framework, Ruby  
>> on Rails  is a framework, etc etc. Moose is not a framework, it is  
>> completely  stand alone and your code doesn't fill in the missing  
>> pieces, instead  it /uses/ Moose to build it's own thing.
>
> Yes, you're right, although it was only intended to be a relative  
> comparison
> between the two. s/is more/is *slightly* more/g to get a better  
> idea of what I
> was thinking.
>
> I meant it in the sense of 'use Moose' being a buy-in to all the Moose
> goodness. You get the extra keywords, the Moose::Object base, and  
> so on.
> In return you have to accept the way that Moose does things OO-wise  
> and put
> a certain trust the route that the taxi driver takes.  But it is a  
> complete
> system. In contrast, Badger is more like a box of bits and some  
> self-assembly
> may be required.

Yup, I agree there too.

>> <snip>
>
> Yes, exactly.  Modulo our slightly different definitions of where the
> metaprogramming stops and the metaprogramming-programming starts :-)

You say metAprogramming I say mEtaprogramming, 'sall works for me.  
The word itself is such an overused term these days (Thanks a Lot  
Ruby guys! sheesh), so the definition is "flexible" :)

But seriously, I see what you mean, the layer between vanilla Perl 5  
OO and Badger is much thiner then between it and Moose.

>> And Moose I am sure would play nicely with Badger.
>
> Yes, they both play together quite well.  I've only tried the  
> basics of
> creating objects using both Badger and Moose, but they both seem quite
> happy in each other's company:
>
> http://badgerpower.com/svnweb/Badger/view/trunk/badger/t/misc/moose.t

Hmm, I should probably put that into the Moose test suite too, that  
way we can be sure to maintain compat.

Excellent, thanks for updating the docs and clarifying, I think I  
have a better idea of what Badger is all about now too. Perhaps there  
may be a BadgerX::Moose and/or MooseX::Badger in the future :)

- Stevan







More information about the templates mailing list