What OO paradigm?

sigzero on 2008-05-01T13:04:56

There is the "standard" way to do Perl objects and there are these things called InsideOut objects that Object::InsideOut and Class::InsideOut help you with.

Do Perl programmers just stick with the "standard" or is InsideOut being used more?

I know there is Moose as well...


Not really standard

autarch on 2008-05-01T14:25:58

I've done a lot of OO in my Perl time, and I've never used Inside Out objects. I've never seen the point.

Nowadays, I'd say that a standard is Moose, and that's what I use. It's far more featureful and clean than any of the Inside Out class helpers, and you can basically ignore the object implementation (hashref, arrayref, inside out, doesn't matter).

Re: What OO paradigm?

Stevan on 2008-05-01T14:35:08

Do Perl programmers just stick with the "standard" or is InsideOut being used more?

DISCLAIMER: I am biased, and all my "facts" come secondhand from people who have switched to Moose, so take it with a big giant grain of salt.

I have been seeing some blowback with Inside-Out objects, mostly centered around the difficulties with dumping them and the need for them to be DESTROY-ed to properly manage them. Most of the helper modules tend to try and fix these issues, but in doing so, they tend to break the "standard" way of doing Perl OOP things. For dumping the object, it's not that bad, but all you need is one junior programmer to write DESTROY instead of DEMOLISH and your Inside-Out objects now have a memory leak. Of course 5.10 fieldhashes fix this, but not everyone is on 5.10 yet.

Moose on the other hand, actually uses the "standard" way to build Perl objects, in the sense that by default it uses HASH references for the instance type. Because of this Moose tends to play very well with non-Moose classes that are also HASH based. Moose really just makes building "standard" Perl objects easier by doing all the tedious bits for you. If your intern writes a DESTROY method on a Moose class it will no longer run all your DEMOLISH methods, but it won't prevent your objects from getting garbage collected.

As for some kind of measure of "popularity", thats always really difficult to discern, but best I can do is tell you what I am seeing. We are getting a lot more activity on the #moose IRC channel and the moose mailing list, and from new people too, not just the regulars. Also I regularly see Moose being discussed and suggested on the Catalyst and DBIx::Class IRC channels and mailing lists. More Moose questions are starting to pop-up on Perlmonks as well. So best I can tell the number of Moose users is growing pretty steadily for the past few months.

I would be interested to know what the Inside-Out module authors are seeing. I know that Class::Std was revived recently, and Class::InsideOut and Object::InsideOut seem to be released regularly, so they do seem alive and well.

- Stevan

Re: What OO paradigm?

dagolden on 2008-05-01T17:22:02

As the author of Class::InsideOut, I would say that people should only use inside-out objects if they have a particular need for doing so and understand the implications. No one should use inside-out objects "just because" or because they think it's a best practice.

I still refer people to my YAPC talk as a good articulation of the issues.

I've only recently had the opportunity to work with Moose and I'm very impressed with it -- though I found a bit of a steep learning curve trying to understand type constraints. Above all, I think Moose benefits from being built upon a well-defined meta object protocol, unlike most of the ad hoc OO helpers out there.

I used to worry how much magic is going on behind the scenes in the dependency chain, but recent CPAN::Testers results have shown improvement.

(Most of the FAIL's are older Perls or places where Scalar::Util is broken, I believe).

-- dagolden

Re: What OO paradigm?

Stevan on 2008-05-01T17:33:29

I used to worry how much magic is going on behind the scenes in the dependency chain, ...

The most magical bit is Sub::Name, followed by some of the XS we have in Class::MOP now (only about 20-30 lines of XS in total too). And recently some of the BestPracticalistas have been looking to make a Pure Perl alternative to that as well. In general we do our very best to keep core Moose as clean and easy to install as possible, and all the crazier stuff (see also MooseX::Compile) is in a different distro.

- Stevan

Re: What OO paradigm?

educated_foo on 2008-05-01T18:36:25

(Most of the FAIL's are older Perls or places where Scalar::Util is broken, I believe).
The comedy here is that almost all of those FAILs can be eliminated by making esoteric Test::* dependencies optional.

I don't use Inside-Out Objects

Shlomi Fish on 2008-05-04T05:27:11

To add to all the good comments here, I'd like to add that I'm not using Inside-Out objects, but rather standard hash-ref-based objects, usually with Class::Accessor, (or Class::Accessor::Fast), ADAMK's Object-Tiny, and I've also done some work with Moose. I'm using everything but Moose mostly to get Accessors, and am still probably making little use of the Moose more-advanced features.

The reason I dislike Inside-Out objects is because I feel that they're too much trouble (like dumping or introspecting them) for too little gain (because I've expereienced very few related problems in hash-ref-OO that Inside-Out objects aim to solve.).

In Test-Run, which is based on Class-Accessor, the ::Base classes have become somewhat complicated, as I needed more features. I have an implementation of walk-method there, a sequence operation, a pluggable helper class, some abstraction to Text::Sprintf::Named and other things. I probably need to ask the Moose mailing list if there are solutions for all these things in Moose. As I said on IRC, "Every sufficiently Complex Class::Accessor program contains contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Moose.".

Neither

TeeJay on 2008-09-07T18:16:25

I think Class::Accessor (or similar) is a more common standard that inside out objects or moose.