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

[xdg]

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".

[Joost]

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?

[xdg]

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.