unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Vitalie Spinu <spinuvit@gmail.com>
Cc: 20420@debbugs.gnu.org
Subject: bug#20420: 25.0.50; eieio methods with optional arguments now fail
Date: Sun, 26 Apr 2015 00:02:51 -0400	[thread overview]
Message-ID: <jwviocjblnc.fsf-monnier+emacsbugs@gnu.org> (raw)
In-Reply-To: <87sibonjz0.fsf@gmail.com> (Vitalie Spinu's message of "Sat, 25 Apr 2015 20:25:39 +0200")

>> That tells me *how* you used it, not *where*.
> I was using it in polymode package for a generic indentation
> functionality:
>   https://github.com/vspinu/polymode/blob/master/polymode-methods.el#L530

[ After figuring out that the code now doesn't do that any more and
  seeing the old code which does do the "nasty" empty-args defmethod.  ]

I see, thanks.  At least the "workaround" did not require more code,
and is marginally more efficient to boot.

Looking more closely at the way this was handled in the older EIEIO
code, the semantics are pretty ugly, so it the fact that it worked is
clearly an accident, and reproducing that exact semantics would
be difficult.

> Aha. Cool! I will have a look. Is there a more elaborate documentation
> somewhere?

No, it's more a wishlist item: add support for formal pseudo-arguments
of the form "&context (<exp> <specializer>)".

> Particularly I don't see "specializer" and "generalizer"
> being properly defined anywhere.

"Specializer" is used commonly in CLOS to refer to the "thing" that can
be either a class type or (eql <value>).  "Generalizer" is not standard
and refers to a thing that takes a value (the actual argument) and finds
its corresponding specializers (i.e. its type(s)).  I took the term from
an article that extended CLOS method-matching.  cl-generic.el does not
directly implement that article, but it's fairly similar.

This said, adding support for &context shouldn't need to do very much
with specializers and generalizers (more specifically, shouldn't require
defining new specializers or generalizers).


        Stefan





  reply	other threads:[~2015-04-26  4:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-24 19:28 bug#20420: 25.0.50; eieio methods with optional arguments now fail Vitalie Spinu
2015-04-24 20:42 ` Stefan Monnier
2015-04-24 23:35   ` Vitalie Spinu
2015-04-25 14:41     ` Stefan Monnier
2015-04-25 18:25       ` Vitalie Spinu
2015-04-26  4:02         ` Stefan Monnier [this message]
2015-04-26 12:00           ` Vitalie Spinu
2015-04-27  4:43             ` Stefan Monnier
2015-05-12  4:19           ` Stefan Monnier
2015-05-12 14:23             ` Vitalie Spinu
2016-05-14 23:01               ` Dmitry Gutov
2016-05-15  1:55                 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwviocjblnc.fsf-monnier+emacsbugs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=20420@debbugs.gnu.org \
    --cc=spinuvit@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

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