On 2011.11.22 8:06 PM, David Golden wrote:
> Attributes -- leaving aside types and coercion -- are you just talking
> about the sugar?
Mostly, and the sugar is very helpful, but not all of it.
There's also the potential runtime performance win. Mouse XS accessors are
significantly faster than pure Perl accessors you write by hand, (Mouse pure
Perl ones are no slower).
It's also handy to be able to list a class' accessors. This is used to allow
the dumping of the data contents of an Event. Not strictly necessary, but it
will be handy for the JSON formatter/dumper.
> And I wonder if Role::Tiny could be extended to do multiple roles.
>
> Or could you do a poor-man's version of roles using mix-ins?
>
> I understand the goal of decomposition and why Mo[ou]se rocks, but for
> a testing framework, maybe simpler is better.
I don't think cobbling together an OO system from bits and bobs, and then
relying on it, makes more sense than using a fully baked one. While
Role::Tiny might load faster, there's no evidence it will compose roles faster.
And there's no evidence loading a bunch of individual OO modules will be any
faster than loading Mouse::Tiny.
Also one of the side benefits of shipping TB2::Mouse is now other Test modules
can rely on it getting the benefit of a fully operational OO system without
adding further dependencies.
Finally, it's a whole lot of regressive work to tear Mouse out. I'd rather do
some investigation into performance optimizations in TB2 and Mouse first
before we go into writing YET ANOTHER PERL OO FRAMEWORK, wheeeeeeeee!
I wonder if I can find an excuse for TB2 to need a template module... ;-)
> For example, Moose will detect method clashes with roles, right? (I
> assume Mouse does that.) Do you really need that? Or could you
> verify the design "by hand" rather than relying on a MOP to do the
> work for you?
I actually don't know. I sure don't need it. But this presumes that's where
the performance problem is.
> How much of it is fundamental to what you're trying to do and how much
> of it is just making life easier for you in implementing it? Granted,
> well tested Mouse might be less buggy than hand-rolled replacement,
> but a special-purpose class framework could possibly be simpler (thus
> faster and less buggy).
None of it is fundamental. All of it is making life easier.
--
Reality is that which, when you stop believing in it, doesn't go away.
-- Phillip K. Dick
