When I wrote Object::Tiny, I didn't bother to write a comparison to Moose because I saw them as being in a completely different ballpark.
One is a fully featured MOP implementation with all the goodies of the Perl 6 object model... and the other makes trivial accessors to save typing.
I saw it as more of a compliment, because obviously we're comparing apples and oranges here.
So then Moose::Tiny shows and I of course assume it's a joke by some random person unrelated to Moose itself.
A little annoyed that they are taking some liberties with the
Much to my surprise, Moose supremo Steven Little turns up in defense of Moose::Tiny suggesting it is a "Hilarious social commentary on the absurd concept of second level namespace ownership".
On the one hand, I don't see a problem with "ownership" (in a sense) of a suffix... there's no difference in the level of protection available. I could easily walk all over DBI:: and there's nothing in PAUSE to stop me.
BUT, if the Moose people do indeed feel that they want to be included in a comparison, well fair enough.
So, how does Moose::Tiny compare to Object::Tiny?
Well, in favour of Moose::Tiny is that it saves one additional character of typing, with an otherwise identical interface.
Installation: Moose::Tiny has a number of recursive dependencies (and a few more build_requires deps not shown) with non-perfect cpan testers results (72% aggregate success installing).
Memory: Moose::Tiny uses 4.5 megabytes of memory. This is around 550 times larger than Object::Tiny, or a more impressive sounding 55,000% larger
Startup: Moose::Tiny takes around a second to load up on the virtual I'm currently working in. Granted that's also in the debugger, so it's WAY slower than it could be, but Object::Tiny does not take any noticable time to load, even in the same scenario.
That's just what I had time to test when I first saw Moose::Tiny uploaded.
I'm not on a computer with a working Perl atm to complete the comparison (Intarweb cafe to check mail), so I'll leave it to someone else to do the rest (accessor speed, et al) but suffice it to say Object::Tiny and Moose really ARE completely different beasts.
moose (Score:1)
A moose once bit my sister...
Re: ::Tiny (Score:1)
Obviously.
Well, your 1/2 right. It is a joke, but the author is heavily involved in the Moose community.
You see, this is the j
Re: (Score:1)
John.
--
Re: (Score:1)
Re: (Score:1)
And I got confused with that versus the joke of trying to apply standards for suffixes.
Thank You (Score:1)
Re: (Score:1)
Re: (Score:1)
Name one.
So far I'm not aware of any modules that are doing that...
Nobody "owns" Config:: or XML:: or even YAML::
Occasionally people specifically ask that a namespace be kept clear for the exclusive benefit of that project, like DBI or PPI or (I assume) Moose.
And neither I or any other
If Moose:: has indeed asked to remain clear, you are the only person that has violated a namespace in the
Re: (Score:1)
Well ... except first I didn't release until I had cleared it with Stevan first. Actually I asked him if I should
release at all, and then again if he felt that it belonged in the Moose namespace. If he'd said no, or was unsure at
any point I wouldn't have released ... MooseX::Tiny is no better than Acme::Moose::Tiny for parody [google.com] purposes.
Second I think a case can be (and has [perl.org] been [perl.org]) made that there is disagreement on the merits of the Tiny naming scheme. Though in those cases I suppose it isn't the To be ho
TagSoup::Tiny (Score:1)
I seem to recall that it wasn't the ::Tiny suffix that really annoyed people earlier this year (but they seem to mind less now that the documentation of said module explains what exactly it doesn't).
Re: (Score:1)
XML people generally don't like XML::Tiny, Ingy doesn't like YAML::Tiny and so on.
Actually, I'm not a huge fan of XML::Tiny either and wouldn't use it myself, but I still think it is necessary and understand why it should exist.
I can see why Moose people might not like Object::Tiny
Ohhh...I get it (Score:1)