[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GOOPS-based SRFI-35 implementation

From: Andreas Rottmann
Subject: Re: GOOPS-based SRFI-35 implementation
Date: Mon, 08 Mar 2004 21:07:45 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Neil Jerram <address@hidden> writes:

> Hmm.  My inclination is that it would be nicer if a compound condition
> straightforwardly satisfied is-a? for all its component condition type
> classes (without specialization of is-a?).  
> The big benefit of this is that methods defined for the component
> types will work on (instances of) the compound type as well, which
> makes sense because we know that the compound type has all the slots
> of the component type.
> The possible problem is that `make-compound-condition' would have to
> construct an appropriate subclass on the fly, and that this should
> interact nicely with compound condition classes created explicitly by
> the programmer, e.g.:

> (define-class &my-condition (&i/o-condition &runtime-condition)
>   ...)
> In other words, given this define-class, the result of
> (make-condition &my-condition ...)
> should be indistinguishable from that of
> (make-compound-condition &i/o-condition (...)
>                          &runtime-condition (...))
I think you mean condition instead of make-compound-condition here.

> but I think this is achievable.
It may be, but this probably involves "caching" defined (via
define-class or the condition macro) condition types by their
supertypes. This, in turn, disallows defining different define-class
statements specifiying the same supers (if the supers are conditions).

Another, much more serious problem is the following:

(define-condition-type &c &condition
  (x c-x))

(define-condition-type &c1 &c
  (a c1-a))

(define-condition-type &c2 &c
  (b c2-b))

(define v2 (condition (&c2 (x "V2") (b "b2"))))
(define v3 (condition (&c1 (x "V3/1") (a "a3"))
                      (&c2 (b "b3"))))
(define v5 (make-compound-condition v2 v3)) ;; This is hairy

Here, we given your proposed model, we'd get this hierarchy:

(define-class &c ())
(define-class &c1 (&c))
(define-class &c2 (&c))
(define-class &c3 (&c1 &c2)) ;; Class constructed for v3
(define-class &c5 (&c2 &c3)) ;; Class constructed for v5

This will cause GOOPS to barf: "merge-lists: Inconsistent precedence graph"

I didn't see an obvious solution to this problem.

Andreas Rottmann         | address@hidden      | address@hidden | address@hidden      | GnuPG Key:
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Make free software, not war!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]