[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GOOPS-based SRFI-35 implementation
Re: GOOPS-based SRFI-35 implementation
Sat, 06 Mar 2004 15:52:36 +0100
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
Neil Jerram <address@hidden> writes:
> Andreas Rottmann <address@hidden> writes:
>> Neil Jerram <address@hidden> writes:
>> > Andreas Rottmann <address@hidden> writes:
>> I've thought of this, too; this was my reason to use GOOPS in the
>> first place.
> Great - our thoughts are very much in sync then. In my view, though,
> the whole idea becomes much nicer and more useful if we integrate it
> with existing Guile exceptions, so I hope we can agree with Marius to
> do this.
Indeed. Making Guile use SRFI-35 conditions everywhere would be a
*very* nice thing to have.
>> Also, there is a class &compound-condition which doesn't exist in
>> the SRFI (so methods for compund conditions can be defined).
> Seems sensible; also that it doesn't exist in the SRFI, because
> &compound-condition is not a condition _type_ (even though it does
> make sense as a GOOPS class). Do you have an example in mind of how
> methods on &compound-condition can be useful?
I've so far only used it this way:
(define-method (handle-condition (c &compound-condition))
((and (message-condition? c)
(format (current-error-port) "itla-debuild: ~A\n" (condition-message c))
(if (abort-condition? c)
(format #t "itla-debuild: unexpected condition ~S\n" c))))
And then somewhere raise a fatal error:
(message (format #f "Current working directory ~S is not part of
working copy build area ~S"
(getcwd) (string-join wc-area-dirs "/"))))
> I'm not sure though about `condition' expanding to
> `make-compound-condition' in the case there is only one type given.
> Is this implied in some way by the SRFI? I think it would be nicer to
> detect the single type case and use `make-condition' instead.
Well, I detect that in make-compound-condition itself, but that's not
the most obvious place (since the name make-compound-condition implies
that a call will indeed result in a compund condition).
>> Plus, there is a macro guard/handle, which calls handle-condition:
>> (define-method (handle-method (&foobar-condition c))
> (Not in the version that you posted, so I presume this is newer.)
Yes, but it's in my Archive:
% tla register-archive
% tla get itla--devo--0.1 itla
% $EDITOR itla/srfi/srfi-35.scm
> Interesting. I'm sceptical that it will be possible to define a
> generally useful handler for a condition, but I could easily be wrong,
> and there is negligible overhead from providing this. (On the other
> hand, it's only a few lines, so perhaps could be left to the
> programmer to write for him/herself when needed?)
I think this might come handy for top-level handlers. If there is
general consensus, I could take this out of (srfi srfi-35), of course.
>> > by SRFI-35. Therefore, for example, `make-condition' would create and
>> > return a GOOPS error/exception class and, given a
>> > error/exception/condition object OBJ, `(condition-has-type? OBJ TYPE)'
>> > would be identical to `(is-a? OBJ TYPE)'.
>> I'd have to specialize is-a? for this, since compound conditions all
>> share a class.
> 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,
That was my initial idea, I then however switched to a separate class
for some reason. "compound-condition-is-derived-class" seems like a
more coherent design to me now, however.
> 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 (...))
> but I think this is achievable.
> This conflicts, though, with the introduction of &compound-condition
> and the idea that &compound-condition provides a way to define methods
> on compound conditions. Since this ability is a Guile extension
> anyway (w.r.t. SRFI-35), I think it would be reasonable to say that
> the way to do this is to define the compound condition class
> explicitly, using define-class as just above.
Sounds like a good plan, I'll look into this.
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
If atheism is a religion, then health is a disease. -- Clark Adams