Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Sunday November 04, 2007
06:48 AM

Object::Tiny vs Moose(::Tiny)

[ #34827 ]

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 ::Tiny suffix, I write a review suggesting Acme::Moose::Tiny would be a vetter name.

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • A moose once bit my sister...

  • 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.

    Obviously.

    So then Moose::Tiny shows and I of course assume it's a joke by some random person unrelated to Moose itself.

    Well, your 1/2 right. It is a joke, but the author is heavily involved in the Moose community.

    A little annoyed that they are taking some liberties with the ::Tiny suffix, ... [snipped other stuff about reviews and such]

    You see, this is the j

    • If it takes that long to explain it the joke probably isn't that funny.

      John.
      --

    • See, I originally thought it was a joke because it was an oxymoron...

      And I got confused with that versus the joke of trying to apply standards for suffixes.
  • 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

    • lying about in people’s packages
      Sorry I meant "Namespaces" not packages.
    • Lying about in people's namespaces?

      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 ::Tiny authors have violated that (although I dearly want to release DateTime::Tiny).

      If Moose:: has indeed asked to remain clear, you are the only person that has violated a namespace in the
      • 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

  • A little annoyed that they are taking some liberties with the ::Tiny suffix...

    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).

    • Indeed, pretty much every ::Tiny module has initially annoyed people that care a lot about doing some particular job the correct way.

      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 :)
  • It is a ::Tiny pissing match going on. : )