guile-devel
[Top][All Lists]
Advanced

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

Re: namespaces, goops, etc.


From: Mikael Djurfeldt
Subject: Re: namespaces, goops, etc.
Date: 09 Nov 2000 22:10:27 +0100
User-agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7

Michael Livshin <address@hidden> writes:

> this sounds like the prohibition of internal `define-class' is just a
> restriction of the current implementation, then?

In GOOPS, classes are first-class objects.  One refers to classes
using ordinary bindings.

For convenience of use (and we're talking about *real* convenience
here---I know the difference between adding a slot to a class
definition and hitting C-M-x, and, rebooting my entire simulation
environment and running the simulation up to the point where I left),
and for compatibility with STKlos and CLOS, define-class invokes the
class redefinition protocol.

It also needs to define accessors for its slots.

So, the semantics of define-class includes

1. Creating and binding the class object
2. Creating and binding the accessors
3. Invoking the class redefinition protocol

To me it seems like strange questions arise when trying to apply this
semantics in lexical scope, for example: If an accessor exists on
top-level, should a define-class in a local scope add a method to the
top-level accessor or should it not?

Also, like yourself, I don't like internal defines.  I think it's a
better idea to introduce a new syntax for local versions of the
top-level macros (let-generic etc), just as we have distinct
define-syntax and let-syntax forms.

Just to clarify the current behaviour and implementation, here's what
define-class in principle (except that defined? is used to make sure
that accessors aren't redefined and that the classname binding isn't
accessed if it doesn't exist), expands to:

(begin
  (define accessor1 ...)
  ...
  (define classname
    (let ((old classname)
          (new (class (inherit1 ...) slot1 ... #:name 'classname)))
      (class-redefinition old new)
      new)))

> 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.

I don't think the implementation part is a problem.  But will it
really work the way we want it to?

Please be more specific.  How should the development environment
behave?  Should top-level defines have more complex semantics than
binding a variable to a value?  Should it check if the object is a
class and invoke the class redefinition protocol?  Should it make
similar exceptions to other kinds of objects?  How should we specify
such exceptions?  Maybe a define MOP?

> > > > 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!

(Just an aside: The plan is to replace the current uses of defined?
with a conditional expansion construct akin to when-eval et al in the
syntax-case package.)

> > 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 think you've hit on a real and annoying problem with GOOPS.  Believe
me, I've spent many hours trying to come up with something better than
the current situation.  But don't let that discourage you.  If you can
come up with something better I'd be very happy.



reply via email to

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