in reply to Decorator(?) classes and inheritance

This seems too easy to be right, but I thought I would throw it out here for my edification if not dragonchild's. How about 

package D;

sub new { Singleton::new( @_ ) };

sub make_attr_subs { ReadOnly::make_attr_subs( @_ ) };

[download]
How does this miss the mark in providing the D behavior you wish?

David

Replies are listed 'Best First'.
Re: Re: Decorator(?) classes and inheritance
by dragonchild (Archbishop) on Jan 30, 2004 at 16:44 UTC
    That does do what I want, program-wise. The issue is that I don't want D to know where Singleton and ReadOnly do their work. As far as D should be concerned, Singleton and ReadOnly automagically do the right thing. For example, make_attr_subs() is a function that the clients of this object family should never know about. Additionally, new() is a function that that the clients are expressly forbidden to override (or the OO contract is violated).

    ------
    We are the carpenters and bricklayers of the Information Age.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]

      I can see why you dont wan't D to understand where ReadOnly does its work, that makes sense, ReadOnly should just shadow the Base class. But I do not understand why you care about D knowing where Singleton does its work. It seems to me that if you are going to create a Singleton, it is obvious that it will do its work at creation time, and so therefore you would need to call Singleton::new().

      I think maybe you are going to far with trying to decouple your class's knowledge of one another. There comes a point in all designs, when you have to say enough is enough. If you have a really compeling reason, let us hear it, otherwise, I would dispatch to Singleton::new() explictly and make that a condition of using the Singleton class.

      One things too that I was unclear on, is if your Singleton class inherits from Base. Your pseudo-code would indicate not, but some of what you are saying makes me think they are supposed to. If that is the case (Singleton is-a Base), then I would recommend a re-thinking of that.

      To be honest though, without seeing alot more code, I can do nothing but speculate here. I have a class framework that I have been working on for the last 2 years, and addresses problems like this very simply by using (Trait/mix-in)-like (pseudo-incomplete) objects, and always seperating the creation of my objects (the new() method) from the initialization (the _init() method in my framework). I also take advantage of the perl symbol table's "hackability" to do Eiffel-like renaming and dispatching of methods, you can check my scratchpad to see a quick example of that type of code (and a more detailed explaination of it in this node for which the scratchpad was created).

      -stvn
[reply]

In Section Seekers of Perl Wisdom