Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Slides from NY Inside-Out Talk

by ghenry (Vicar)
on Jan 19, 2006 at 11:37 UTC ( #524189=perlnews: print w/replies, xml ) Need Help??

Just in case you missed it:

use Perl article: Slides from NY Inside-Out Talk

PDF: Inside-Out objects talk

Walking the road to enlightenment... I found a penguin and a camel on the way.....
Fancy a Just ask!!!

Replies are listed 'Best First'.
Re: Slides from NY Inside-Out Talk
by Ovid (Cardinal) on Jan 19, 2006 at 21:51 UTC

    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?


    New address of my CGI Course.

      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.


      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.

Re: Slides from NY Inside-Out Talk
by xdg (Monsignor) on Jan 19, 2006 at 17:52 UTC

    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.


    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.

Re: Slides from NY Inside-Out Talk
by zentara (Archbishop) on Jan 19, 2006 at 12:02 UTC
    That's a nice pdf.

    I'm not really a human, but I play one on earth. flash japh

      That's a nice pdf.

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

      Cheers, Sören

Re: Slides from NY Inside-Out Talk
by merlyn (Sage) on Jan 19, 2006 at 19:15 UTC
    I'm not sure why Abigail gets credit in slide 2 for something I distinctly remember in Damian's Object-Oriented Perl book, predating Abigail's presentation by roughly 3 years, especially when the last slide also credits Damian's OOP book. Does anyone know why history is being rewritten here?

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      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

      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.


      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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlnews [id://524189]
[stevieb]: atcroft: "Make both hands into fists..."... is something my Ma taught me in our native lang, but I was to ignorant and young to pay attention. Thanks for that :)
[atcroft]: stevieb: Sad to say that I only recently learned that particular trick, but I have since found it very useful.... :)
[james28909]: ill be back with a solution eventually
[stevieb]: it's a reminder to re-inforce it :P
[atcroft]: james28909: That particular questions was a bit of trick, actually (depending on the country you are in). More interesting is, if you are trying to subtract from an epoch time, for instance, you might have to consider when/if DST occurs for a location,
[atcroft]: because you may have to adjust the number of seconds you change from an epoch from 86400 (not to mention leap seconds)....
[atcroft]: james28909: Although if your program is using a database, you might be able to "pass the buck" to the database and ask it to do the date change for you....

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (3)
As of 2017-04-29 04:37 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (531 votes). Check out past polls.