unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Generic-methods from multiple modules should  merge
@ 2006-01-10 19:36 Alan Grover
  2006-01-10 22:06 ` Marius Vollmer
  0 siblings, 1 reply; 3+ messages in thread
From: Alan Grover @ 2006-01-10 19:36 UTC (permalink / 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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Generic-methods from multiple modules should  merge
  2006-01-10 19:36 Generic-methods from multiple modules should merge Alan Grover
@ 2006-01-10 22:06 ` Marius Vollmer
  2006-01-11  1:20   ` Alan Grover
  0 siblings, 1 reply; 3+ messages in thread
From: Marius Vollmer @ 2006-01-10 22:06 UTC (permalink / raw)
  Cc: guile-user

Alan Grover <awgrover@mail.msen.com> writes:

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

You can do this by using a 'duplicates' handler when defining the
importing module.  The 'duplicates' handler determines what is going
to be done to bindings with the same name.  The 'merge-generics'
handler is probably what you are looking for.  See NEWS in CVS HEAD.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Generic-methods from multiple modules should  merge
  2006-01-10 22:06 ` Marius Vollmer
@ 2006-01-11  1:20   ` Alan Grover
  0 siblings, 0 replies; 3+ messages in thread
From: Alan Grover @ 2006-01-11  1:20 UTC (permalink / raw)


Yes, lovely section in the NEWS outlining the exact problem, and the
behavior I expect. Though I think that merge-generics should be the
default behavior.

I suppose I'll have to to try to upgrade.

Marius Vollmer wrote:
> Alan Grover <awgrover@mail.msen.com> writes:
> 
> 
>>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.
> 
> 
> You can do this by using a 'duplicates' handler when defining the
> importing module.  The 'duplicates' handler determines what is going
> to be done to bindings with the same name.  The 'merge-generics'
> handler is probably what you are looking for.  See NEWS in CVS HEAD.
> 


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-01-11  1:20 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-01-10 19:36 Generic-methods from multiple modules should merge Alan Grover
2006-01-10 22:06 ` Marius Vollmer
2006-01-11  1:20   ` Alan Grover

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