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