[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
c?
(x c-x))
(define-condition-type &c1 &c
c1?
(a c1-a))
(define-condition-type &c2 &c
c2?
(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.
Andy
--
Andreas Rottmann | address@hidden | address@hidden | address@hidden
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Make free software, not war!