Re^2: Really Writing Object Oriented Perl

I agree. IMHO there's one thing that would help this whole situation: there should be a default, modern, easy to use OO framework/library that's recommended for serious work by the majority of "the perl/OO community" (if there is one).

Something that:

Can subclass any other class that's using bless() the right way with any reference type. (I.e. it should use the inside-out fields technique)
works with threads (and fork() emulation on windows) - won't use reference addresses to index fields.
works with threads::shared - allows you to share objects across threads with minimal fuss.
works with XS extensions and allows for easy mixed perl/XS classes/hierarchies.

The only thing I can think of is Object::InsideOut, though it could use a simple tutorial, some XS helper functions and possibly a less cluttered interface. Other suggestions are welcome.

If the community can decide on some default library like that, it should be put in the core.

I know the tendency is to keep as much as possible out of the core, but a default good OO layer (i.e. not Class::Struct) is just plain needed to be able to write good OO perl. It really is too much work to write reliable OO perl without using external modules.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Comment on Re^2: Really Writing Object Oriented Perl

Replies are listed 'Best First'.
Re^3: Really Writing Object Oriented Perl by shmem (Chancellor) on Jun 03, 2007 at 20:59 UTC
There's a small but (I hope) steadily growing ressource about OO on PerlMonks: Anno's meditations, replies and questions. While his intentions might be different, I perceive his as an effort to implement OO requirements as close as possible to or into the perl core, with what means perl itself already provides. Following this road one day we might not only have the basics needed to implement an OO system in perl - functions as methods, packages as classes, references, bless, ref and so on - but a robust OO system at the core level, not just tacked-on OO implementations in disparate arbitrary and sometimes redundant or contradictory modules on CPAN. OO is "magic" - and the perl sense of "magic" fits; I am looking forward to OO related "Magic Virtual Tables" (see perlguts for those) and handling code, either in the perl core, or in some XS extension provided along with the core. Anno's inside-out iplementation via magicext seems to meet all the requirements you have outlined so far. A lot of fuzziness will have to be discussed and cleaned up to meet that goal - first thing that comes to mind is the ambiguous use of package, module and class - they are often used as synonyms, but address very different aspects needed for a robust OO implementation; then method lookup... --shmem _($_=" "x(1<<5)."?\n".q·/)Oo. G°\ / /\_¯/(q / ---------------------------- \__(m.====·.(_("always off the crowd"))."· ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}	[reply]
Re^4: Really Writing Object Oriented Perl by Joost (Canon) on Jun 05, 2007 at 01:36 UTC
Thanks for that link. Anno's solution looks pretty good to me, but sharing objects across threads doesn't work "out of the box". It might be fixable but my perl/threads knowledge is pretty basic. Question: is there any hook to catch that an object is shareable (i.e. shared() is called on it) or does the call to CLONE specify that somewhere? I can't seem to find any decent documentation on CLONE(). XS hooks seem to be very straightforward to implement with this technique. Much easier than with inside-out objects, anyway. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^5: Really Writing Object Oriented Perl by shmem (Chancellor) on Jun 05, 2007 at 11:15 UTC
Question: is there any hook to catch that an object is shareable (i.e. shared() is called on it) or does the call to CLONE specify that somewhere? Isn't that done by setting the :shared attribute on an object? i.e. marking an object as shareable is up to the caller using a module which uses Alter. AFAIK the CLONE() special subroutine has to do with package and/or class data only. I can't seem to find any decent documentation on CLONE(). I don't know if there's much more documentation about that than what perldelta tells: Support for the "CLONE" special subroutine had been added. With ithreads, when a new thread is created, all Perl data is cloned, however non-Perl data cannot be cloned automatically. In "CLONE" you can do whatever you need to do, like for example handle the cloning of non-Perl data, if necessary. "CLONE" will be executed once for every package that has it defined or inherited. It will be called in the context of the new thread, so all modifications are made in the new area. See perlmod Sine the object instance data is attached to an Alter object itself, no special provision for cloning has to be taken by the Alter package; sharing those objects in threads should be as straight forward as sharing simple scalar references. I don't know for shure, but the magicext structure should automatically be cloned as well for shared objects (I haven't done much yet with threads). Whether you shoot yourself into your foot depends on what you pass into the ego() subroutine upon object construction, i.e that could be some class data reference which isn't shared or shareable. --shmem _($_=" "x(1<<5)."?\n".q·/)Oo. G°\ / /\_¯/(q / ---------------------------- \__(m.====·.(_("always off the crowd"))."· ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}	[reply]