From: Alan Grover <awgrover@mail.msen.com>
Subject: Generic-methods from multiple modules should merge
Date: Tue, 10 Jan 2006 14:36:19 -0500 [thread overview]
Message-ID: <43C40CB3.5070702@mail.msen.com> (raw)
I have 2 goops classes, each in their own module, which happen to have a
slot called 'request (with an accessor). Unfortunately, "use-modules"
ends up importing the generic-method from only one of the modules (the
last, lexically). Thus, I can't call (request first-class).
Thus:
(use-modules (awg first-class))
(use-modules (awg second-class))
...
(request some-object-of-first-class)
=> No applicable method .... [on first-class]
; and, if you introspected on the generic-method 'request,
; you'd only see one method/procedure.
This seems documented in the manual under "Module System Quirks:"
When two or more used modules export bindings with the same
names, the last accessed module wins.
If the generic-method/accessor were part of a logical interface, then a
super-class could declare it, and my 2 (sub-) classes would add their
methods to the generic-method, and everything would be fine.
However, the two classes don't share an interface, they just happen to
have the same slot-name (admittedly with the same object in it). It
doesn't strike me as right to use a super-class such as
"request-accessor-class" with just that slot/accessor. Imagine doing
this for each case: 'color, 'phone-number, 'etc.
And renaming seems wrong, not to mention tedious. I'd have to remember
which class's accessor had been renamed (or not).
I think the right thing is to have the module system "merge" the generic
methods. Thus, when importing a module, if the module's symbol is bound
to a generic-method, and if the symbol is already bound to a
generic-method (in the "using" module), add the methods to the existing
generic-method. Then, all of the methods are visible under the generic name.
Actually, instead of merging into the existing generic-method, a new
generic-method should be created in the "using" module, and the two
"used" ones merged in to that. I believe this preserves the expectations
of lexical scope better.
On the other hand, I believe a similar existing situation behaves
differently: Importing a generic-function, and then "adding" a method to
it does modify the generic-function as seen by the "used" module.
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
next reply other threads:[~2006-01-10 19:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-10 19:36 Alan Grover [this message]
2006-01-10 22:06 ` Generic-methods from multiple modules should merge Marius Vollmer
2006-01-11 1:20 ` Alan Grover
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=43C40CB3.5070702@mail.msen.com \
--to=awgrover@mail.msen.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.
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).