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] |
Maciej Stachowiak <mstachow@mit.edu> writes: > mdj@nada.kth.se writes: > > Or maybe: > > > > make-getter-with-setter > > I think `make-procedure-with-setter' makes more sense. Why? If the procedure has a setter it should be a getter, the names will be shorter and the selector names more sensible. (I have an argument for `*procedure*' but I'd like to know why you prefer it.) > How about calling this `has-setter?' (that would nicely encapsulate > the case of generic functions that have setters). I look upon make-getter-with-setter as a constructor of a new type of object (sub-type of procedure). I think all types should have a type predicate. The natural name would be its type name followed by a question-mark. > Also, calling a procedure-with-setter normally should call the getter, > thus making `getter' somewhat superfluous except for pedantic > completeness. I'm not so sure that it is only pedantic. At least during program development, especially during debugging, it is nice to be able to retrieve the getter procedure. > Perhaps a generic function could always effectively be a > procedure-with-setter, but would automatically recompute a generic > function to be its setter whenever a method is added. I'm not sure if > this substantially differs from your suggestion above. Please explain this a little bit further. > Or, to avoid the need for magic entirely, each generic could have an > associated setter generic and the user would be required to add > methods to that explicitly. This is a possibility, but then we're back to a situation where the mechanism spreads over the entire language. It would be nice to isolate it a bit, so that ordinary generics don't have to care a bit about setters. (Also, note that we can't let the associated setter be a slot in the generic, unless we introduce read-only slots.) > > (Yes, this whole issue would have a very simple answer if Guile had > > the object system builtin.) > > How so? My thought was: (set! (G A1 A2 ...) V) --> ((setter G) V A1 A2 ...) <=> ((slot-ref G 'setter) V A1 A2 ...) But it doesn't work until we have read-only slots... /mdj