Re^2: Introducing Class::InsideOut

My one point of critique is: ->new doesn't only create but also initializes objects. This is wrong, simply because (in an inheritance situation) you want to create only one object (call ->new, bless it into a class), but initialize the object to work with not only the class itself, but one or more superclasses. If creation and initialization are forced together, that gets awkward.

By design, Class::InsideOut doesn't provide new(). Users are free to combine creation and initialization, or to separate them, based on personal preference and design needs. Somewhere along the line, register() has to be called, but that's the only requirement. I'm supporting of people subclassing Class::InsideOut to provide a new/init structure. (I intend to do one myself when I get a chance.)

A minor point of critique is that you seem to be cache-ing inheritance data that could change at run time. The cache could get out of sync.

Technically, it caches at run-time at the point of first use. E.g., the first time DESTROY is called, the cache is built. Hopefully, at that point, any run-time @ISA manipulations are done.

I'd also like to point out a novel (to my knowledge) method to do desctruction of inside-out objects. Instead of following the inheritance tree, you can look at the object and see which classes it is initialized to. With a little collaboration from the user, you can see that by inspecting which field hashes have existing keys with the object's id. The field hashes of these classes must be cleared (and their DEMOLISHers called).

By ignoring @ISA you wind up having to search through all registered properties. From looking at your code, it looks like your approach searches through all properties to generate a list of classes and then iterates back over those classes to do the destruction. That's seems to me like a potentially big computational hit for a DESTROY method -- particularly if lots of inside-out classes exists and if lots of objects are created and destroyed.

Class::InsideOut uses @ISA and the cache to try to minimize the inevitable overhead of DESTROY. While the caching might be a little too aggressive a form of early optimization, I think @ISA is a good way of avoiding having to do an exhaustive search.

That said, I think your code is an interesting start at an alternative. If you decide to continue developing it, I suggest you look at the slides from my talk on inside-out objects for ideas on some of the incremental features you may want to support. (You may find that doing so will complicate the elegance of your design.)

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

Comment on Re^2: Introducing Class::InsideOut Select or Download Code

Replies are listed 'Best First'.
Re^3: Introducing Class::InsideOut by Anonymous Monk on Feb 13, 2006 at 21:18 UTC
I (Anno) wrote: My one point of critique is: ->new doesn't only create but also initializes objects... To which you (xdg) replied By design, Class::InsideOut doesn't provide new()... Right. It looks like I misunderstood your design when I wrote that. Main point of critique withdrawn. However, I think I would go so far and enforce the separation of creation and initialization. As a designer, it gives you one more point of control (`->new` is your baby now). Your users fully control object construction through their `->init` methods. This may be the zealotry of the newly-converted (you monks will understand). I have written functional OO Perl where `->new` initialized its object like everyone else's `->new`, and I thought I was doing fine. Now I find that with the separation many things fall into place, not only in coding practice, but conceptually too. With inside-out classes, it is the effect of the individual `->init` calls (one for each class the object is going to be used with) that `DESTROY` must undo. The result of `->new` takes care of itself, like with standard objects. Anno: I'd also like to point out a novel (to my knowledge) method to do desctruction of inside-out objects. Instead of following the inheritance tree, you can look at the object and see which classes it is initialized to... xdg: By ignoring @ISA you wind up having to search through all registered properties... It's not that bad. I walk through all registered classes, checking a single hash key for existence. That tells me which classes the object has been initialized to, presumably the same set an `@ISA` analysis would return. There are situations where this gets inefficient (many classes, little inheritance). The method can be refined so that the classes an object is initialized to are known without a search, but that burdens initialization a bit. It's a tradeoff over the life-cycle of an object. My point is that `DESTROY` should read things off the object. If the inheritance tree is allowed to change, an object could have been constructed according to one situation, but be destroyed in another. Even relying on the live `@ISA` tree could get destruction wrong in that case. xdg: I suggest you look at the slides from my talk on inside-out objects for ideas on some of the incremental features you may want to support. (You may find that doing so will complicate the elegance of your design.)... There speaks the saddened voice of experience. Don't I know it! At the moment I much prefer churning out pretty little sketches of various designs, mostly for my own edification. As for additional features, before seeing your slides I'm thinking of a dump/stringification/persistence function (dump a necessity, persistence is good). I might add an "accumulate" feature (call methods of a name for a set of classes, with a way to specify the inheritance ancestry for that set). I'd have to look at its utility. It gets complex when different parameters must be passed to different classes. Oh, and the threads-issue must be addressed somehow. I'll look at your slides and see what else comes up. Regards, Anno	[reply] [d/l] [select]
Re^4: Introducing Class::InsideOut by adrianh (Chancellor) on Feb 14, 2006 at 15:56 UTC
However, I think I would go so far and enforce the separation of creation and initialization. As a designer, it gives you one more point of control (->new is your baby now). Your users fully control object construction through their ->init methods. But if you're providing your own new you lose the ability to subclass other classes that are not based on your system. An extremely nice feature of Class::InsideOut IMO.	[reply]
Re^5: Introducing Class::InsideOut by Anno (Deacon) on Feb 15, 2006 at 09:46 UTC
Why? The common `new` can support it: `sub new { my $class = shift; bless @_ ? shift : \ my $x, $class; }` [download] That way you can use an arbitrary foreign object as the donator of the new id. Anno	[reply] [d/l] [select]
Re^6: Introducing Class::InsideOut by adrianh (Chancellor) on Feb 15, 2006 at 10:42 UTC
Re^7: Introducing Class::InsideOut by xdg (Monsignor) on Feb 15, 2006 at 12:20 UTC
Some notes below your chosen depth have not been shown here


No such thing as a small change
	PerlMonks