unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mikael Djurfeldt <djurfeldt@nada.kth.se>
Cc: djurfeldt@nada.kth.se
Subject: Re: where to put generics?
Date: Mon, 14 Jul 2003 18:42:35 +0200	[thread overview]
Message-ID: <xy74r1p2h6s.fsf@nada.kth.se> (raw)
In-Reply-To: <20030712103036.GB4329@lark> (Andy Wingo's message of "Sat, 12 Jul 2003 11:30:36 +0100")

Andy Wingo <wingo@pobox.com> writes:

> I figured while I was emailing I could get something else off my chest
> -- what is the best way for two modules that do not want to know about
> each other to add methods to the same generic? The problem there is that
> such a generic might not exist in the 'stock' top-level environment. The
> generic would need to be created and then exported, but only one time --
> if both modules export generics, the generics from recent modules will
> replace those from previous modules.
>
> So, if the generics are only exported once, where should they be put?
> I'm hacking around this for the moment by putting them in the root
> module, but that's not exactly an elegant solution. What's the thought
> on this? Has anyone else had to deal with these issues in the past?

Firstly, Gregor Kiczales, the author of CLOS, has discussed issues
related to this in his paper "Issues In the Design and Specification
of Class Libraries", OOPSLA92
(http://kvast.blakulla.net/mdj/kiczales92.pdf).  It is a very
elucidating read.  The way to think about it is that a module is
publishing an interface with certain functionality and a generic
function can be used to provide part of this functionality.  If one
follows certain rules listed in his paper when extending generic
functions, most problems will disappear.

Secondly, I've made an attempt at another kind of solution.  Let's
assume that module A exports a generic foo which both modules B and C
want to add methods to, but B don't want to be confused by C's methods
and vice versa.  You can then do this:

(define-module (A)
  :export (foo))

(define-method (foo ...) ...) (1)

(define-module (B)
  :use-module ((A) :prefix A:))

(define-extended-generic foo A:foo)

(define-method (foo ...) ...) (2)

and a similar code for module C.

The extended generic function foo becomes a descendant of A:foo and
A:foo becomes an ancestor of foo, but they are still distinct generic
functions.  Methods added to foo in module B will belong to foo only,
but can be accessed from all descendants and ancestors.  Conversely,
any generic function can access the methods added to all of its
descendants and ancestors.  This means that module A can run methods
from modules B and C, while B and C won't be able to access
eachother's methods.

The second operand of define-extended-generic can also be a list of
generic functions.  This can be used to "merge" generic functions from
different modules.  There is also a recent addition to the module
system which can do this automagically.  Search for "merge-generics"
in the NEWS file.

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel


      reply	other threads:[~2003-07-14 16:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-12 10:30 where to put generics? Andy Wingo
2003-07-14 16:42 ` Mikael Djurfeldt [this message]

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

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

  git send-email \
    --in-reply-to=xy74r1p2h6s.fsf@nada.kth.se \
    --to=djurfeldt@nada.kth.se \
    /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.
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).