Re: goops and memoization

[Neil Jerram <neil@ossau.uklinux.net>]

>>>>> "Mikael" == Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:

    Mikael> [...] because the list of applicable methods is unique per
    Mikael> application arglist signature and gf application also
    Mikael> caches per application, not per method definition.

I see this now.  A case that makes it clear is this:

(define-method (foo (arg <super1>))
  ...
  (next-method))
(define-class <derived> (<super1> <super2>))
(define-method (foo (arg <super2>))
  ...)
(foo (make <derived> ...))

The first define-method cannot possibly know at definition time that,
in the eventual application, next-method should be pointing to the
method for super2.

There is also this, which doesn't rely on multiple inheritance ...

(define-class <base>)
(define-class <derived1> (<base>))
(define-class <derived2> (<derived1>))
(define-method (foo (arg <base>))
  ...)
(define-method (foo (arg <derived2>))
  ...
  (next-method))
(foo (make <derived2> ...))
(define-method (foo (arg <derived1>))
  ...
  (next-method))
(foo (make <derived2> ...))

But this one could be handled by fixing up the next-method chain when
the method for <derived1> is defined, so isn't such a compelling
example.

I'm not proposing to pursue the method-definition-time approach.  Out
of interest, however, are there any hard cases that don't rely on
multiple inheritance?

        Neil



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