[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22336: 25.0.50; cl-generic.el features are not documented in ELisp m

From: Eli Zaretskii
Subject: bug#22336: 25.0.50; cl-generic.el features are not documented in ELisp manual
Date: Sun, 24 Jan 2016 16:34:01 +0200

> From: Stefan Monnier <address@hidden>
> Cc: Eli Zaretskii <address@hidden>,  address@hidden
> Date: Sun, 24 Jan 2016 00:03:21 -0500
> > (cl-defgeneric foo (a)
> >   (:method ((s string)) "stringy!")
> >   (:method ((a array)) :four)
> >   10)
> I implemented this :method thingy simply because CLOS allows it, but I'm
> not sure it's worth documenting.

':method' is in the doc string, which for me was a clear sign it
should be documented.

> > But the docstrings don't mention any of the possible values of TYPE (except
> > (eql ...)), not just "plain old" ones. So I'm not clear on what exactly you
> > consider an omission here. cl-defmethod docstring should probably enumerate
> > the possible types (aside from the mentioned ones, TYPE can be (head ...)
> > or a name of cl-struct, like the commentary says).
> Actually, the only "builtin" specializer is t (the generic one).
> All other ones are defined via cl-generic-define-generalizer, and we
> should improve cl-defmethod's docstring so that it automatically
> mentions all the specializers that happen to be currently defined
> (i.e. in a dynamic way, just like pcase's docstring dynamically lists
> the patterns currently defined via pcase-defmacro).

Such dynamically-updated doc string would be very good to have, I
think, but I needed to work with what was there, and of course
couldn't use the kind of intimate knowledge of the implementation that
you have.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]