* cl-defmethod specializer widget ?
@ 2022-01-26 14:09 Pierre L. Nageoire
2022-01-27 6:28 ` Stefan Monnier via Users list for the GNU Emacs text editor
0 siblings, 1 reply; 3+ messages in thread
From: Pierre L. Nageoire @ 2022-01-26 14:09 UTC (permalink / raw)
To: help-gnu-emacs
Hi,
I wonder why it is not possible to use widget as specializer in
cl-defmethod. Indeed it is not declared in the suitable list but could
it be added without trouble ; since a widgetp function exists. But maybe
it is not enough.
Similarly function is not accepted but it could be comfortable .
Regards
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: cl-defmethod specializer widget ?
2022-01-26 14:09 cl-defmethod specializer widget ? Pierre L. Nageoire
@ 2022-01-27 6:28 ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-01-28 6:35 ` Pierre L. Nageoire
0 siblings, 1 reply; 3+ messages in thread
From: Stefan Monnier via Users list for the GNU Emacs text editor @ 2022-01-27 6:28 UTC (permalink / raw)
To: help-gnu-emacs
> I wonder why it is not possible to use widget as specializer in cl-defmethod.
Because the current code only works for types that can be inferred
solely from the value of (type-of OBJ), basically.
You can add support for `widget` as a specializer in two ways:
- Redefine widgets to use their own *real* type (i.e. with
`cl-defstruct`) instead of (ab)using symbols and cons cells.
- Add a method to `cl-generic-generalizers` to handle `widget` in an
ad-hoc way.
> Indeed it is not declared in the suitable list but could
> it be added without trouble ;
It would slow down dispatch, but only of those generic functions that
contain methods specializing on `widget`.
> Similarly function is not accepted but it could be comfortable .
Indeed, for the same reason: a value of the form (closure ...) or
(lambda ...) is a valid function, currently, but `type-of` returns
`cons` and not all `cons` are functions, so it would require
an additional method in `cl-generic-generalizers`.
Stefan
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: cl-defmethod specializer widget ?
2022-01-27 6:28 ` Stefan Monnier via Users list for the GNU Emacs text editor
@ 2022-01-28 6:35 ` Pierre L. Nageoire
0 siblings, 0 replies; 3+ messages in thread
From: Pierre L. Nageoire @ 2022-01-28 6:35 UTC (permalink / raw)
To: Stefan Monnier via Users list for the GNU Emacs text editor
Cc: Stefan Monnier
thanks Stefan ! That is clear !
Pierre
Stefan Monnier via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:
>> I wonder why it is not possible to use widget as specializer in cl-defmethod.
>
> Because the current code only works for types that can be inferred
> solely from the value of (type-of OBJ), basically.
>
> You can add support for `widget` as a specializer in two ways:
> - Redefine widgets to use their own *real* type (i.e. with
> `cl-defstruct`) instead of (ab)using symbols and cons cells.
> - Add a method to `cl-generic-generalizers` to handle `widget` in an
> ad-hoc way.
>
>> Indeed it is not declared in the suitable list but could
>> it be added without trouble ;
>
> It would slow down dispatch, but only of those generic functions that
> contain methods specializing on `widget`.
>
>> Similarly function is not accepted but it could be comfortable .
>
> Indeed, for the same reason: a value of the form (closure ...) or
> (lambda ...) is a valid function, currently, but `type-of` returns
> `cons` and not all `cons` are functions, so it would require
> an additional method in `cl-generic-generalizers`.
>
>
> Stefan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-01-28 6:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-01-26 14:09 cl-defmethod specializer widget ? Pierre L. Nageoire
2022-01-27 6:28 ` Stefan Monnier via Users list for the GNU Emacs text editor
2022-01-28 6:35 ` Pierre L. Nageoire
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).