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:
> 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? 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 > > 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 > _______________________________________________ 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 |
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."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. 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 |
Free forum by Nabble | Edit this page |