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