Re: Keywords in GOOPS methods

[Mikael Djurfeldt <mikael@djurfeldt.com>]

[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]

Hi Maxime,

Well, these particular examples aren't valid since GOOPS doesn't allow type
specifiers for keyword arguments. (It's the same in CLOS.) Type dispatch is
done *only* on the required arguments.

Best regards,
Mikael

On Sat, Nov 23, 2024 at 4:31 PM Maxime Devos <maximedevos@telenet.be> wrote:

> >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
>

[-- Attachment #2: Type: text/html, Size: 5052 bytes --]