[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: namespaces, goops, etc.
From: |
Michael Livshin |
Subject: |
Re: namespaces, goops, etc. |
Date: |
08 Nov 2000 22:53:03 +0200 |
User-agent: |
Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (20 Minutes to Nikko) |
Mikael Djurfeldt <address@hidden> writes:
> Michael Livshin <address@hidden> writes:
>
> > > 1. define-class - class redefinition protocol
> >
> > so you give up consistency for magic that you don't even need, really.
>
> Well, I can tell you that I'm not entirely happy about the current
> solution. But I really tried to get the least amount of magic with
> preserved convenience of use.
>
> The magic involved is that the expansion of `define-class' uses
> `defined?'. Otherwise it expands to plain Scheme code.
this sounds like the prohibition of internal `define-class' is just a
restriction of the current implementation, then?
if you are redefining a class, it's better to have the development
environment notice it somehow than to resort to `defined?', IMHO. it
may require more effort to implement, but the result is more
consistent and no less useful.
> > * non-interactively, in a running program.
> >
> > if this were up to me, I would _not_ invoke the class redefinition
> > protocol magically in this case.
>
> I don't get it. How would the current `define-class' be used
> non-interactively in a running program?
I've mixed it up with `change-object-class', apparently. was too
sleepy, sorry.
> > > 2. define-method - may need to define the GF
> >
> > so it can define it in the same local scope. I don't see any problem
> > here.
>
> Again, this sounds like magic to me. Can you explain how the
> expansion of `define-method' should look like?
ISTR syntax-case allowing stuff like this pretty easily, but please
don't believe anything I say until I prove it with references!
> If you have a suggestion on how to improve these macros which is still
> convenient to use, I'm very interested.
I seem to have got myself into an interesting position here. I happen
to not like inconsistencies. but in this case the inconsistency is
with a Scheme feature I don't even like -- namely internal defines.
unfortunately, Scheme is stuck with them, so I feel a vague but
pressing need to resolve the inconsistency, or at least to whine
loudly about it ;).
I may well be just overreacting. if you think so, feel free to ignore
this.
--
I have seen the future, and it does not work.