Nice slides. I see that my Class::BuildMethods faired poorly, but for reasons other than what I expected. I was generally against the idea of adding anything to this as I deliberately wanted the code to be simple, but from what I can see from your slides, there are some extremely useful features I can provide while still maintaining the simplicity.

Out of curiosity, what technique would you suggest for me to avoid the HoH? I could create a package hash inside of each class and store things there directly, but that breaks encapsulation. However, it only does that in the "please stay out of the kitchen" sense, not in the "decouple code from implementation" sense. Do you think that would be sane?

For the purpose for which you intend Class::BuildMethods, I don't think the HoH is a big deal. It mandates accessors, but that's an acceptable style choice if you're not trying to provide the full inside-out capability set. You could use a package global (I do that in Object::LocalVars) but there's some speed penalty there due to the extra redirection. (I'm pretty indifferent, personally, on advisory versus enforced encapsulation.)

More critical, I think, is adding a CLONE method for thread/pseudo-fork safety if you really want to offer a robust module, particularly for users on Win32. The tricky bit will be registering the objects without losing simplicity. Short of adding a method like Class::InsideOut::register, you may need to register the object behind the scenes in the accessors when values are set. (Prior to any properties being set, there's minimal, if any, harm if the objects aren't registered.) That's simplicity at the cost of efficiency, of course.

Storable support is the other issue you may want to address. Serializing inside-out objects with Data::Dumper is difficult. From what I understand, modules like CGI::Session can also serialize with Storable which isn't too hard to support. However, if you don't add that support, you should at least document the lack as many people just assume that any object can be serialized.

For both of those, you should be able to crib fairly freely from Class::InsideOut -- the code is fairly clean and should adapt to your implementation without a lot of fuss.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Thanks for highlighting it here. I'd mentioned that I'd posted the slides on the earlier thread, but many people may have missed it there.

And thank you those those offering compliments. Let me say that I couldn't have written it without all the excellent discourse on inside out objects here on Perlmonks so let me give my thanks to all those who added to those. I'll add a special thanks to jkeenan1 and jdhedden for their editorial review and suggestions prior to the talk.

Though I mention it in the references section of the slides, I've got a fairly comprehensive list of PM threads on inside-out objects at xdg's scratchpad for those who are new to the topic.

That's a nice pdf.

Very good reading. Informative and easy to follow. (++)

Cheers, Sören

I drew a distinction between "inside-out" (lexicals for each property) and "flyweight" (single lexical holding hashrefs for each object). That may be arbitrary, but I think it's significant as inside-out, defined that way, makes property names into lexical identifiers that can be checked with strict, unlike hash keys:

# regular object
$self->{name} = "Larry"; # name is a hash key

# flyweight object, as per Damian's book
my @objects;
$objects->[$$self]->{name} = "Moe"; # name is a hash key

# inside-out object
my %name;
$name{ refaddr $self } = "Curly"; # name is a lexical variable
[download]

I don't have TheDamian's Object-Oriented Perl handy at the moment, but I don't recall that it went beyond the flyweight idea. Abigail-II's talk on Lexical::Attributes was the first I'd seen of it, and I hadn't come across any prior art before Re: Where/When is OO useful?.

I certainly believe that Abigail was building upon Damian's foundation -- a point that I made verbally in the talk on p.9, which shows the evolution from class properties to the flyweight pattern as a setup for explaining the inside-out pattern.

I included Damian's book in the reference as valuable background material in general, as this was an introductory talk and I did cover the flyweight pattern, albeit briefly.

If I have overlooked some prior art there or elsewhere, I welcome a specific correction and citation and would be happy to include it in the talk.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.