This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
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.