in reply to Re: Threads and fork and CLONE, oh my!
in thread Threads and fork and CLONE, oh my!

There are definitely advantages to using inside-out / flyweight objects: they're light-weight, relatively simple to implement and give you private, per-package properties (no more worries about inheriting classes messing up your properties, yay!).

Now basing the flyweight "key" on the object's ref-address also makes it much harder to accidentally modify the key, you don't need any seperate algorithm to generate unique keys, and since all objects have a ref-address, you can inherit from any "normal" class with an inside-out subclass and vice-versa (vice-versa provided the top-class propagates DESTROY).

Now, there is only a problem with this approach if you use ithreads. I don't know about you, but I've not used ithreads except as a toy; for me, I'm not sure that the benefits of ithreads are worth the risk :-) It's not like they're completely devoid of bugs and caveats.

Update: I completely glossed over the win32 fork() problems. I didn't even know that a fork() on win32 would modify your ref-address (I use win32 only when I *really* have to). Still, I can imagine situations where you'd want the above code, but I'd use a special-purpose flyweight key if I'd have a choice in the matter.

  • Comment on Re^2: Threads and fork and CLONE, oh my!

Replies are listed 'Best First'.
Re^3: Threads and fork and CLONE, oh my! (SEP)
by tye (Sage) on Aug 12, 2005 at 23:32 UTC

    IMO, this is just one more way iThreads and Perl's fork emulation on Win32 are fundamentally broken. Given that they are already "the worst of both worlds" and buggy, my reaction to this realization would be just to mark any code I have that uses 0+$ref (or refaddr) as "Not supported with iThreads nor with Win32 fork()".

    - tye        

Re^3: Threads and fork and CLONE, oh my!
by adrianh (Chancellor) on Aug 17, 2005 at 15:04 UTC
    they're light-weight

    If we're talking memory usage then they're not significantly more lightweight than normal blessed hashes on recent perls.