Wait, your confusing me now :P

:) I'll take it that this is now redundant. My objections are not "whether" OO or Moose are useful, powerful desirable. Just when.

And the 'bugs' I alluded to were purely hypothetical. The point being that as systems become more complex, the costs of managing and negotiating between the sub-component authors grows exponentially. Users of complex systems have to take that into account when deciding if the benefits of re-use of those complex systems outweigh the costs to them. Including when things go wrong inside those systems.

If a users application requires, and will benefit from, a large proportion of the features--code generation, introspection, etc.--that Moose provides in buckets, then it's a no-brainer to stand on the shoulders of those that write and maintain that complex, powerful and well-designed system, rather than starting from scratch.

For the OPs application, as described, I do not think those criteria are met.

The guys over at Best Practical are trying to replace all my XS usage with Pure Perl alternatives,

Whilst I think that Pure Perl alternatives have some merit, I also think that the (further) performance hit of removing all the XS code from Moose would be a mistake. Most XS code will compile on Win32/AS, with only minor changes. The difficulty is in locating them.

Oh, please do, I would love to convert you :)

I don't need converting to the benefits of OO--used appropriately. As far as Moose is concerned, I'm already convinced that is is "best of breed" for projects requiring its featured. Far better than most everything else in the Class::* and Object::* name-spaces.

Could you be more specific as to what you mean? I would happily remove a dependency if the replacement were as simple as that.

It's not just about simple substitution. It also about choosing to use some of them.

• Sub::Uplevel

  From the Caveats:

  Well, the bad news is uplevel() is about 5 times slower than a normal function call. XS implementation anyone?

  Perl's function calls are already slow. Moose places (of necessity for its function) many extra layers of function call over raw access. Rather than adding another layer, who's only purpose is to deceive, it would far better (for everyone) to give full traceback (ala Carp cluck/croak)), than to impose the performance & misinformation penalties of "hiding the truth".

• Sub::Exporter. a sophisticated exporter for custom-built routines.

  There's a lot going on inside this module. That's a result of the power of the features it can provide.

  The question is: Is Moose using or benefiting from that power? Would Exporter or Exporter::Lite, or even just a custom import() serve Moose equally well for its needs, and avoid some of the overhead?

• Sub::Name -(re-)names a subroutine.

  What does return subname 'Moose::Role::extends' => sub {... }; buy you that

  *Moose::Role::extends = sub{ ... }; (or even: sub Moose::Role::extends {...} doesn't?

  (I think I may understand the reasoning behind not using the latter, but better that you decide one way or another yourself

FWIW, to use Moose, you really just need to read...

Sophisticated systems require a good deal of good documentation. My comments were simply to defuse the notion that use of accessors/getters simplifies maintenance of nested, built-in data-structures.

The question here is: do you need or benefit from the sophisticated system (for your specific application)?.

For this application, loose wrappings around built-in data-types, my conclusion is no. That in no way detracts from Moose when used for that for which it is intended.