Re^2: RFR: Inside-out classes - a Class::InsideOut primer

Hm, some very good points. First off, thanks for pointing out the stray semi-colon -- it's an artifact from cleaning up the original HTML (there used to be an > there). Second, thanks for the clarification on get_hook, I must have simply mis-read the documentation: my bad.

I'm of two minds about including the longer form of register... on the one hand, it would be more accurate, on the other, it does seem a little more confusing. It's clear that what I've got is probably inadequate, but I will have to give some thought to how much of that behavior I want to explain. That, and how best to convey it.

As for the importance of the id function, would you care to expand? I'm certainly not an expert on inside-out objects, and I've just been using it as a bit of a mantra -- when I need the ID of an object, I do it this way -- I'd appreciate more insight into why I'm doing it. I can then distill that insight down (hopefully) into primer-appropriate materials.

I call Class::Std "deprecated" on the basis that I would discourage its use to anyone who didn't really know what they were doing. I hadn't considered that others would take "deprecated" in different contexts; I will have to think about how to rephrase that.

Thanks for the link to your presentation, I will look it over and consider it for mention.

<–radiant.matrix–>
Ramblings and references
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet

Comment on Re^2: RFR: Inside-out classes - a Class::InsideOut primer Select or Download Code

Replies are listed 'Best First'.
Re^3: RFR: Inside-out classes - a Class::InsideOut primer by xdg (Monsignor) on Mar 16, 2007 at 15:12 UTC
As for the importance of the id function, would you care to expand? ... I'd appreciate more insight into why I'm doing it The real answer: Class::InsideOut expects/requires that the unique key for each object be its memory address (to ensure safety for threading and pseudoforks), so it provides the alias `id()` to `Scalar::Util::refaddr`. To explain it in the primer, it may be sufficient to say that each object needs to have a unique key and Class::InsideOut requires the use of the `id()` function to generate that unique key. Regarding `Class::Std`: I would discourage its use to anyone who didn't really know what they were doing. I think this is almost exactly what you should say in place of "deprecated". -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.	[reply] [d/l] [select]
Re^4: RFR: Inside-out classes - a Class::InsideOut primer by Joost (Canon) on Mar 16, 2007 at 15:19 UTC
The real answer: Class::InsideOut expects/requires that the unique key for each object be its memory address (to ensure safety for threading and pseudoforks), so it provides the alias id() to Scalar::Util::refaddr. I don't have a win32 perl available to test this right now, but doesn't a fork() in win32 perl change the refaddr? If so, does anyone know if Class::InsideOut handles that correctly? "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^5: RFR: Inside-out classes - a Class::InsideOut primer by xdg (Monsignor) on Mar 16, 2007 at 15:34 UTC
does anyone know if Class::InsideOut handles that correctly Yes. See Threads and fork and CLONE, oh my!. It's specifically what Class::InsideOut was designed to get right for inside-out objects and what Class::Std still gets wrong. Object::InsideOut gets it right, too, and adds features for cross-thread sharing. But the API and features of O::IO are a bit daunting. -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.	[reply]