This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Trouble understanding define (!)


Neil Jerram <neil@ossau.uklinux.net> writes:

> (This is a very useful paper - and a pity that I didn't read
> it before attempting to document the MOP!)  It would be good to
> support automatic assertions here.

Yes, it is useful.  But, if you feel like making changes to your
current draft---please go ahead!  :)  I'll try to produce my comments
this weekend, but you shouldn't feel that you have to wait for that.

Also, we actually should rewrite most uses of `slot-ref' and
`slot-set!' using accessors instead, since this will very soon be the
canonical way to access slots.

> According to Jost, Bertrand Meyer recommends a restriction that is, I
> think, a generalization of Kiczales' rules, viz. that an application
> should never be able to modify a module's internal state in such a way
> that the behaviour observable by another application is different.

What is the "internal state" of a module?

I hope it doesn't include the set of methods in a GF exported by the
module, because such a rule would be a mistake.

Note that GOOPS is centered around *operations* and that the data such
operations work upon flow freely past module boundaries.  Thus, in
most cases, when extending a GF, it is important that also the
exporting module uses the new methods we have added when operating on
data of the type defined in the importing module.

Typical example is the MOP.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]