Email list hosting service & mailing list manager

Re: where is srfi-17 going? Jost Boekemeier (25 Jan 2000 09:29 UTC)
Re: where is srfi-17 going? sperber@xxxxxx (25 Jan 2000 10:19 UTC)
Re: where is srfi-17 going? Jost Boekemeier (25 Jan 2000 10:57 UTC)

Re: where is srfi-17 going? Jost Boekemeier 25 Jan 2000 09:29 UTC

Mikael Djurfeldt wrote:

> It's quite easy: I did.

> There are several reasons, but the primary one is that we use this
> operator extensively in our object system.  We use the accessors to
> get and set values of slots.  Ex:

>  (set! (n o) 4711)

> means use accessor n to mutate object o so that (n o) returns 4711.

This object system seems to be broken.  In any reasonable object
system it is *not* possible to set! the value of one of the object
slots directly.

You can send a message to an object asking it to change its internal
state.  The object may or may not accept this message.  But you cannot
simply grab its internals and change them.

This is the difference between classes and structures.  You can (and
must) change the internals of structure values from the outside while
the internals of an object are opaque to you.  An agressive compiler
however can optimize a change-value message into a simple set!

Even if the interface specifies that some object internals can be
changed from the outside that doesn't mean that you can simply grab
the internals, pass them around and change them later. There may be
other constraints which you don't know, for example there may be a
monitor associated with the object.  This means that "(set! (n o)
4711)" is simply syntactic shugar for (change-preferred-parfum o 4711).