"Bengt Richter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> See if this does what you want:
>
> [snipped]
>
Yes, that's pretty much what I had in mind. I particularly liked the
idea of mirroring automagically the nested class inheritance in each
version. So I tried to refine th
George Sakkis <[EMAIL PROTECTED]> wrote:
>>A1 - A2 - A3 - A4 - ...
>>||||
>>B1 - B2 - + - B4 - ...
>>||||
>>C1 - + - C3 - + - ...
>>||||
>>D1 - D2 - + - D4 - ...
>>||||
>> The solution is simply to include C3 in th
On 9 Apr 2005 03:49:19 -0700, "George Sakkis" <[EMAIL PROTECTED]> wrote:
>"Michael Spencer" <[EMAIL PROTECTED]> wrote:
>>
>> George,
>>
>> since you explicit allowed metaprogramming hacks :-), how about
>something like
>> this (not tested beyond what you see):
>>
>> [snipped]
>>
>
>Nice try, but i
Dirk wrote:
> So I dug through the documentation and found that new-style classes
> compute a monotonic linearization of the inheritance graph, observing
>local precedence order, using the algorithm also used in Dylan
> described here:
>http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
George Sakkis wrote:
Have you considered a 'macro' solution composing source?
Can you elaborate on this a little ? You mean something like a
template-based code generating script that creates all the boilerplate
code for each version before you start customising it ?
I was thinking more along the
Hi George,
it's a nice little puzzle and it is more fun to solve it if one is not
a student anymore :)
Filling the gaps in the lattice is somehow necessary but it is not
necessary to create all the classes.
Ansatz:
We can consider two matrices: one is filled with nodes ( class names )
the other
> Have you considered a 'macro' solution composing source? If I were
handling so
> many versions, I would want a complete class definition for each
version rather
> than having to scan many sources for each implementation.
Can you elaborate on this a little ? You mean something like a
template-ba
> On second thought, I had doubts. Consider the following scenario:
>
>A2 | f <- A3
>^ ^
>| |
>B2 | f <- B3
>^ ^
>| |
>C2 <- C3 | g
>
> Assume g calls f. Since f is defined in B version 2, it should taken
>
It may be useful to separate the code into version-independent part and
version-dependent part. Also, one can try to implement the higher-level
logic directly in the class definition of A, B, etc., and then use the
version objects only as patches for the details. That is, one can use
place-holder c
Dirk Thierbach <[EMAIL PROTECTED]> wrote:
> Ok. Multiple inheritance can often select priority for conflicting
> methods. If you can specify yhat tou want "column priority" for
> each class, you're fine.
On second thought, I had doubts. Consider the following scenario:
A2 | f <- A3
^
George Sakkis wrote:
Nice try, but ideally all boilerplate classes would rather be avoided
(at least being written explicitly).
It depends on how much magic you are prepared to accept; this goal is somewhat
in conflict with the next one...
Also, it is not obvious in your
solution why and which p
"Michael Spencer" <[EMAIL PROTECTED]> wrote:
>
> George,
>
> since you explicit allowed metaprogramming hacks :-), how about
something like
> this (not tested beyond what you see):
>
> [snipped]
>
Nice try, but ideally all boilerplate classes would rather be avoided
(at least being written explici
George Sakkis wrote:
I'm not sure if it was clear to you, but my problem is the dummy
WorldModel_v1.MovableObject class. It doesn't do anything by itself,
but it has to be in the inheritance chain to make its descendants work
properly.
George,
since you explicit allowed metaprogramming hacks :-),
George Sakkis <[EMAIL PROTECTED]> wrote:
> 1. There is a (single inheritance) hierarchy of domain classes, say
> A<-B<-..<-Z (arrows point to the parent in the inheritance tree).
> 2. This hierarchy evolved over time to different versions for each
> class. So for example, version's 1 hierarchy wou
>
I'm not sure if it was clear to you, but my problem is the dummy
WorldModel_v1.MovableObject class. It doesn't do anything by itself,
but it has to be in the inheritance chain to make its descendants work
properly.
> Are you using the *_v1 naming convention for backwards compatibility?
> Backw
On Fri, Apr 08, 2005 at 06:40:54PM -0700, George Sakkis wrote:
> > Err, you might want to explain what these things do instead of an
> > abstract description of how you are doing it. It looks like you are
> > using inheritance in the normal way _and_ you are using it to handle
> > versioning of so
> Err, you might want to explain what these things do instead of an
> abstract description of how you are doing it. It looks like you are
> using inheritance in the normal way _and_ you are using it to handle
> versioning of some kind (maybe stable interface releases? I don't
know).
>
> Let us kno
On Fri, Apr 08, 2005 at 04:42:52PM -0700, George Sakkis wrote:
> I'm looking for a design to a problem I came across, which goes like
> this (no, it's not homework):
>
> 1. There is a (single inheritance) hierarchy of domain classes, say
> A<-B<-..<-Z (arrows point to the parent in the inheritance
I'm looking for a design to a problem I came across, which goes like
this (no, it's not homework):
1. There is a (single inheritance) hierarchy of domain classes, say
A<-B<-..<-Z (arrows point to the parent in the inheritance tree).
2. This hierarchy evolved over time to different versions for eac
19 matches
Mail list logo
