Guile Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
Guile Home |
Main Index |
Thread Index