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] |
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