[GOODIE] BinaryRelation

Richard A. O'Keefe ok at cs.otago.ac.nz
Fri Mar 28 04:24:01 UTC 2003


Avi Bryant <avi at beta4.com> made an interesting suggestion.
	
	Have you considered splitting the interface into two separate classes,
	each with the same protocol?  That is, rather than having (public) #source
	and #target versions of every method, have source and target wrapper
	objects (perspectives?) that are backed by the same data.  I would guess
	that many users of the BinaryRelation are always going to be navigating in
	one direction or the other

My guess was that this would -not- be so; if someone is happy with one-way
navigation, there are simpler ways than BinaryRelation to get there.

	- if they were handed the appropiate
	perspective, they wouldn't even necessarily have to realize they were
	using anything but a dictionary.
	
Well, no.  Remember that relations are multivalued, and dictionaries are not.
You could make a view look like a dictionary holding sets (which is,
let's face it, what the current implementation actually _is_).

The idea of saying
    targets := aBinaryRelation sourceToTargetView at: aSource
rather than
    targets := aBinaryRelation targetsAt: aSource

has the great merit of providing method names without "source" and
"target" in them.  However, such a one-sided view is still rather
unusual in that it's like a dictionary of sets, not a dictionary of things.
Pretty much anything you might want to do with a dictionary of sets would
be simpler with compound messages, e.g.,
    (aDic at: key) includes: val
=>   aDic at: key includes: val
and the set of messages you'd end up with would pretty much be (more than
half of) the BinaryRelation messages, no?

With the current implementation, no problem, the sets are actually there,
although exposing them doesn't really appeal.
With another implementation, there might not actually be any Set objects
as such stored internally.

It seems like a lot of work to hide the symmetry of something whose
reason for existence is to be symmetric.

I've got to think about this one, but it's exactly the kind of
thought-provoking response I was hoping for.  Thanks.



More information about the Squeak-dev mailing list