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 _______________________________________________ templates mailing list templates@template-toolkit.org http://mail.template-toolkit.org/mailman/listinfo/templates
