This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: generic method names for collections



jglascoe@jay.giss.nasa.gov writes:
> On Sun, 8 Nov 1998, Maciej Stachowiak wrote:
> 
> > 
> > jglascoe@jay.giss.nasa.gov writes:
> > > 
> > > Imagine that we're choosing names for generic methods on collection data
> > > structures...  now, what's wrong with this picture:
> > > 
> > > (set! vector 0 "foo")
> > > (set! vector 0)      ;; oops, forgot the third argument, I'm screwed now!
> > > 
> > 
> > If I were changing the language radically enough that making (set!
> > vector 0 "foo") were legal, I'd instead opt for making the syntax be
> > 
> > (set! (vector-ref vector 0) "foo")
> > 
> > That's the solution that Common Lisp takes essentially, and there is
> > no ambiguity or vast potential for error here.
> 
> no offense, but that's just plain ugly.

Which part do you think is ugly, the use of `vector-ref', or the
genericization of `set!'? Obviously there needs to be a generic name
for "access element at numerical index"

>  Maybe it's best that lists and
> vectors not take part in the MOP.  (OTOH, maybe they should ???  maybe we
> could call their MOP-partaking siblings "arrays" and "pairs") 
> 



> But anyway, I see no reason why generic method names need be tied down to
> the meaningless triplet ref/set!/del!  We should choose more
> understandable names for the benefit of Scheme-newcomers. 
> 
> > Or, assuming you had a generic "ref" (maybe "index" would be a better
> > name in a generic function world, assuming indexing by integer is
> > distinct from looking up by an arbitrary key or something, or maybe
> > "dereference" if you want to be anally correct) :
> > 
> > (set! (ref vector 0) "foo")
> 
> better, but still ugly.
> 

Why? It's precisely parallel to "a = 7;" vs. "b[10] = 99;" vs "x.y =
77" in C. Assignment to locations is made generic. This is a big win
because you only have to remember the names of accessors, not the
names of mutators.

> > In other words, if you want to make everything generic, setting a
> > location that you can get in some way should be made generic.
> 
> I like the "same thing but under a different name" approach:
> 
> (define foo (make-mop-vector 7))  ;; mop-vector, perl-list, foo-bar ???

It's useful to be able to use normal vectors and lists in the generic
world and MOPs make this possible.

> (vector-set! foo 2 "two")         ;; ERROR
> (insert! foo 2 "two") => "two"

But insert! is completely wrong for vectors. `insert!' very strongly
implies adding a new element, and in particular adding a new element
in between two existing ones in a numerically indexed context, which
is not what the above does at all.

> (vector-ref foo 2)                ;; ERROR
> (lookup foo 2) => "two"     
> 
> (vector? foo) => #f
> (vector? (slot-value foo 'proxy)) => #t
> 

Now _that_ part is ugly. Since a MOP can let you import native types
into the OO world without much hassle, why do this silly dance?


> etc.
> 
> okay, strings having "set!" as a substring have different meanings. 
> "vector-set!" and "set!" are obviously different animals.  I was just
> lumping the two together because (in my feeble-minded way) I was imagining
> that
> 
> $generic_name = $name;
> $generic_name =~ s/\S+-(\S+)/$1/; 
> 
> would be your basic approach to choosing a generic method name.
> 

Yeah, but as we've seen already this won't work for vectors and lists
anyway.

 - Maciej