getter argument of register-getter-with-setter!
Shiro Kawai
(30 Jul 2020 11:59 UTC)
|
Re: getter argument of register-getter-with-setter!
Taylan Kammer
(30 Jul 2020 23:50 UTC)
|
Re: getter argument of register-getter-with-setter!
Arthur A. Gleckler
(30 Nov 2020 19:45 UTC)
|
Re: getter argument of register-getter-with-setter! Taylan Kammer (01 Dec 2020 22:15 UTC)
|
Re: getter argument of register-getter-with-setter!
Arthur A. Gleckler
(20 Jan 2021 01:36 UTC)
|
Re: getter argument of register-getter-with-setter!
Arthur A. Gleckler
(08 Apr 2021 17:30 UTC)
|
Re: getter argument of register-getter-with-setter!
Shiro Kawai
(08 Apr 2021 19:31 UTC)
|
Re: getter argument of register-getter-with-setter!
Arthur A. Gleckler
(08 Apr 2021 20:00 UTC)
|
> On Thu, Jul 30, 2020 at 4:50 PM Taylan Kammer <xxxxxx@gmail.com > <mailto:xxxxxx@gmail.com>> wrote: > > ``` > If sparse? is false, the getter will be called with two arguments: the > object whose field should be accessed, and an object identifying the > field to be accessed. If sparse? is true, the getter might be called > with a third argument, the default value, which the getter must return > in case the given object has no value associated with the given field. > > If an implementation of this SRFI ever calls the getter of a sparse > type with two arguments, and the > > The setter will always be called with three arguments: the object that > is to be mutated, an object identifying which field of the object is to > be mutated, and the new value that is to be assigned to that field. > ``` > > Does that sound right? Am a bit tired so the more eyes the better. :-) It really shows that I was tired, given that apparently I didn't even finish one of the sentences. Two changes: 1. Drop the middle paragraph with the broken sentence. 2. In the first paragraph, change the phrase "the getter might be called with a third argument" to "will be called with a third argument." The rationale for point 2 is: an implementation can't know whether a given getter supports a two-argument call, so it will always call the given getter with a default arg to handle the not-found situation itself. (Like the reference implementation does.) If a smarter implementation knows that one of the natively supported types offers its own specific error type and doesn't want to "shadow" it, it can "secretly" call that natively supported getter with two args; this has no bearing on the specification. As such, the result is as follows: ``` If sparse? is false, the getter will be called with two arguments: the object whose field should be accessed, and an object identifying the field to be accessed. If sparse? is true, the getter will be called with a third argument, the default value, which the getter must return in case the given object has no value associated with the given field. The setter will always be called with three arguments: the object that is to be mutated, an object identifying which field of the object is to be mutated, and the new value that is to be assigned to that field. ``` I'm pretty sure this is the best way to specify it, but Shiro's input would be much appreciated. :-) - Taylan