Daniel,
[snip]
I hope we are thinking about the problem in a wrong way, because we've come across the issue in more than one place already. Or maybe, we can figure out a good way of doing it here! (Me thinks of Desing Pattern?)
I wish I had a clear idea of which Design Pattern aplies here, but none is straightforward.
Or, no. Actually I can think of a number of patterns, but most imply lots of manual coding I'm afraid.
I like the solution that you have more than I like the solution that we had come up with. It involves a bit less redundance of code.
Well, the thing to try and do if see if you can redefine the callbacks to be generator methods. In this way they get generated and you use %Dictionary objects to create the appropriate code. And you could inherit your classes from BB and CC since you say this happens in a number of places in your design, hence the "role" in the names of the skeletons I posted and the abstract modifier :)
Still, it seems that any time you add a field to class BB, class CC has to be 'informed' about this new field. I whish I could stay away from duplication of knowledge, but maybe there is no way to do it.
That's a tricky one. Maybe using inheritance can save you this grief.
Or idea of re-writing CC to be almost an exact copy of BB and of overwriting the getters in CC to see if they had a local value is really nasty. We have some working code doing that already, and I loath it.
I can imagine :)
Thanks for the reply... and I hope you don't stop there :) Hope others jump in too.
Yes, they have :) I wonder what Herman would say to this...
-- ZCacheLib - Open Source Extensions for Cach� http://www.zcachelib.org
