Pardon my ignorance, since most of this is out of my league.  Doesn't
this make garbage collection essentially ineffective?  There's also some
flag about coupling being raised in the back of my mind, but I am not
yet able to articulate it.

That being said, I am thoroughly intrigued.  If I can get my mind around
it and see its benefit I might try to implement it in Java (which I am
forced to use during my day job).

=jason
[:question | ^One] 

  >  -----Original Message-----
  >  From: squeak-dev-bounces at lists.squeakfoundation.org 
  >  [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
  >  Behalf Of Richard A. O'Keefe
  >  Sent: Thursday, March 27, 2003 11:24 PM
  >  To: squeak-dev at lists.squeakfoundation.org
  >  Subject: Re: [GOODIE] BinaryRelation
  >  
  >  
  >  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.
  >  
  >  
  >  
  >  ---
  >  Incoming mail is certified Virus Free.
  >  Checked by AVG anti-virus system (http://www.grisoft.com).
  >  Version: 6.0.454 / Virus Database: 253 - Release Date: 2/10/2003
  >   
  >  

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.454 / Virus Database: 253 - Release Date: 2/10/2003