[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Keywords in GOOPS methods
From: |
Maxime Devos |
Subject: |
RE: Keywords in GOOPS methods |
Date: |
Sat, 23 Nov 2024 16:31:42 +0100 |
>Any opinions on what is best: Having a define-method* or having the
>functionality in define-method itself?
You can’t unify define-method with define-method* without making some arbitrary
choices in some special cases (the same applies to define-method* too actually,
and also to define-method on its own without keyword arguments, but it needs to
be considered and documented somewhere).
Consider (please ignore syntax errors, don’t have much practice with GOOPS):
(define-method (f (a <keyword>) (b <integer>))
(pk 'positional a b))
;; what I mean is to only consider ‘foo’ that are of class <number>, I don’t
mean <number> as default value
(define-method (f (#:key foo <number>))
(pk 'keyword foo))
An ambiguous case: (f #:foo 1). This matches both the first and second
implementation. <integer> is more specific that <number>, so this sounds like
the first method should win. But, ‘#:foo’ is more specific than <keyword>, so
the second should win.
I don’t know what the rule is for positional arguments (I assume earlier
arguments are more important in case of ambiguity?). However, the same rule
cannot be applied to keyword arguments, since they aren’t positional. Consider:
(define-method (g (#:key foo <integer>) (#:key bar <object>))
(pk 'integer foo))
(define-method (g (#:key bar <symbol>) (#:key foo <object>))
(pk 'symbol bar))
(g #:foo 1 #:bar a) ;integer or symbol?
(g #:bar a #:foo 1) ;does this produce the same result?
Either ‘integer’ or ‘symbol’ would be appropriate, but it shouldn’t depend on
whether #:foo or #:bar is written first in the argument call. Now #:foo and
#:bar need to be (ideally deterministically) ordered, but any particular
ordering is somewhat arbitrary, and it’s a bit against the notion of keyword
arguments – orderings are more a thing for _positional_ arguments.
Potential escape: in case of ambiguity, give up and throw some kind of
exception. Not ideal, but at least it’s not random, doesn’t depend on how the
keyword arguments were worded, and it would be limited to keyword methods.
Best regards,
Maime Devos
- Re: Keywords in GOOPS methods, (continued)
- Re: Keywords in GOOPS methods, Mikael Djurfeldt, 2024/11/21
- Re: Keywords in GOOPS methods, Tomas Volf, 2024/11/22
- Re: Keywords in GOOPS methods, Mikael Djurfeldt, 2024/11/22
- Re: Keywords in GOOPS methods, janneke, 2024/11/22
- Re: Keywords in GOOPS methods, Mikael Djurfeldt, 2024/11/22
- Re: Keywords in GOOPS methods, Mikael Djurfeldt, 2024/11/22
- Keywords in define-method, Mikael Djurfeldt, 2024/11/25
- Re: Keywords in define-method, Mikael Djurfeldt, 2024/11/25
- Re: Keywords in define-method, Mikael Djurfeldt, 2024/11/26
- Re: Keywords in define-method, Mikael Djurfeldt, 2024/11/26
- RE: Keywords in GOOPS methods,
Maxime Devos <=
- Re: Keywords in GOOPS methods, Mikael Djurfeldt, 2024/11/23
- RE: Keywords in GOOPS methods, Maxime Devos, 2024/11/23
- Re: Keywords in GOOPS methods, Mikael Djurfeldt, 2024/11/24