comparing to an exact class & storing class association relationships

I am trying to record and work with the non-inheritance relationships
between classes.  For example I have...

C subclasses B which subclasses A
E subclasses D which subclasses A
A <-- B <-- C
A <-- D <-- E
with an 1 to N association relationship between B & E.

A class >> relations
    ^ {}

B class >> relations
    ^ { E -> #addE: }

the executing 'B relations' returns the list.  Now in terms of the
model, it is correct that C inherits the relationship to E,
but in terms of drawing the class relationships on screen, there should
be nothing drawn between C & E.
The problem is that executing 'C relations' returns { E -> #addE: } but
I don't want to draw that.

One fix would be a FORCED requirement to define #relations returning ^{}
on EVERY class that does not have its own relations,
but I want to avoid having to do that.

Another fix is doing...
B class >> relations
    (self isKindOf: B class)
        ifTrue:  [ ^ {     E-> #addE.  }     ]
        ifFalse: [ ^ {}  ]

except #isKindOf includes subclasses.  Is there another method that
compares to an EXACT class?

I have also considered storing a classes relationships in a class
instance variable, which I think would work, but it lacks the visibility
that doing it in code has. Also I hit the same issue with with lazy
initialization of that variable per class.

Or... am I approaching this all wrong?  Is there another way?

cheers, Ben


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Ben Coman wrote:
doh! <smacks-head>   funny how it works itself out when you step away
for a while - this works fine...

B class >> relations
   (self == B)
       ifTrue:  [ ^ {     E-> #addE.  }     ]
       ifFalse: [ ^ {}  ]

but I still wonder if it is the right approach

cheers -ben

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

>>>>> "Ben" == Ben Coman <[hidden email]> writes:

Ben> doh! <smacks-head>   funny how it works itself out when you step away for a
Ben> while - this works fine...

Ben> B class >> relations
Ben>   (self == B)
Ben>       ifTrue:  [ ^ {     E-> #addE.  }     ]
Ben>       ifFalse: [ ^ {}  ]

Ben> but I still wonder if it is the right approach

Without further analysis, or description of the problem you're trying to
solve, this already looks far too fragile for me.

For one, it fails the "null subclass" test.  You should always be able
to subclass a class, putting no methods in the subclass, and the
subclass and superclass objects would be completely interchangeable.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

Randal L. Schwartz wrote:

"Ben" == Ben Coman [hidden email] writes:
            

Ben> doh! <smacks-head>   funny how it works itself out when you step away for a
Ben> while - this works fine...

Ben> B class >> relations
Ben>   (self == B)
Ben>       ifTrue:  [ ^ {     E-> #addE.  }     ]
Ben>       ifFalse: [ ^ {}  ]

Ben> but I still wonder if it is the right approach

Without further analysis, or description of the problem you're trying to
solve, this already looks far too fragile for me.

For one, it fails the "null subclass" test.  You should always be able
to subclass a class, putting no methods in the subclass, and the
subclass and superclass objects would be completely interchangeable.

  

I've been taking my time to wrap my head around your comment.  It makes complete sense when thinking about the use of the object model.  However (if you can refer to the attached diagram showing one association and one inheritance relationship) what I am trying to work out is whether that applies as strongly one level up at the meta / class description. 

If ConductingEquipment is a null-subclass then at the instance/model level it could be completely interchanged with Equipment because the association is inherited.  However at the meta / class-description level (ie storing the data to be able to redraw that diagram) ConductingEquipment and Equipment seem not interchangable since no direct line exists between ConductingEquipment to EquipmentContainer.

I'll continue to muse on that. Thanks for you reply.
cheers -ben

_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners