[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Functional record "setters", a different approach
From: |
Ludovic Courtès |
Subject: |
Re: Functional record "setters", a different approach |
Date: |
Sat, 10 Nov 2012 22:40:41 +0100 |
User-agent: |
Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) |
Mark H Weaver <address@hidden> skribis:
> address@hidden (Ludovic Courtès) writes:
[...]
>> BTW, why does ‘set-field’ has the record as its 2nd argument instead of
>> 1st (unlike ‘set-fields’)?
>
> Good question. I followed the syntax of 'set-field' from your original
> patch, but that argument order did not make sense for 'set-fields'.
In the meantime we concurred on IRC that keeping the record as the first
argument in both cases may be best.
>> +The @code{(srfi srfi-9 gnu)} module extends SRFI-9 with facilities to
>> +return new record instances based on existing ones, only with one or
>> +more field values address@hidden setters}. First, the
>> address@hidden works like
>> address@hidden, except that setters are defined as functional
>> +setters.
>
> "except that the fields are immutable and the setters are ..."
OK.
>> address@hidden {Scheme Syntax} set-field (field sub-fields ...) record value
>> +Return a new record of @var{record}'s type whose fields are equal to
>> +the corresponding fields of @var{record} except for the one specified by
>> address@hidden
>> +
>> address@hidden must be the name of the getter corresponding to the field of
>> address@hidden being ``set''. Subsequent @var{sub-fields} must be record
>
> This is the first time that "getter" is used, but it has not been made
> clear that you mean what has been called an "accessor" elsewhere in the
> doc. More generally, there is a confusing mixture of the
> accessor/modifier and getter/setter terminology. I wonder if it would
> made sense to do some kind of find/replace in this section.
Yeah. I ended up leaving “getter”, because that’s the term used in the
SRFI-9 node from the beginning. But I agree we might need to do some
find/replace at some point.
Ludo’.
- Re: Functional record "setters", a different approach, Mark H Weaver, 2012/11/07
- Re: Functional record "setters", a different approach, Mark H Weaver, 2012/11/08
- Re: Functional record "setters", a different approach, Ludovic Courtès, 2012/11/08
- Re: Functional record "setters", a different approach, Mark H Weaver, 2012/11/08
- Re: Functional record "setters", a different approach, Ludovic Courtès, 2012/11/10
- Re: Functional record "setters", a different approach, Mark H Weaver, 2012/11/10
- Re: Functional record "setters", a different approach,
Ludovic Courtès <=
- Re: Functional record "setters", a different approach, Mark H Weaver, 2012/11/09