> in draft status until 2000/04/16

I assume this should be 2000/06/16

> This model makes possible that vectors be regular instances of the
> object system since the object system allows fields to be regular [...]
> or indexed.

Why is it necessary to hard-wire a collection type?  Isn't it better to
parameterize a vector class with another class and use this as the
field descriptor?  And what about other collection types than vectors?

> The proposed model is based on simple inheritance (for the same
> reasons Java took).

(I assume you mean "single interitance")

Java supports multiple interitance via delegation.  Is this
possible in meroon?

> They use keywords ie symbols prefixed with a colon.

In Scheme a colon is a valid identifier.  And I find the :keyword
syntax a little bit strange.  Instead of:

   (instantiate Foo :bar 1 :hux 2 3 4)

I prefer:

   (instantiate Foo (bar 1) (hux 2 3 4))

> (set-Foo-hux! aFooInstance anySchemeValue aNaturalNumber) -> unspecified

The convention for getters and setters is: <type>-<operation>-<field>
Where <type> and/or <field> is optional.

Examples:

       set-cdr!
       set!
string-set!

So this should be:
(Foo-set-hux! aFooInstance aNaturalNumber anySchemeValue)

> (define-class class-name ...)

I assume all classes "live" in a meta namespace which is probably the
same namespace that holds all modules.  But:

> (object->class object)

Does it create a new class?  If so, in which namespace?

> This document proposes an open model in the dynamic spirit of Scheme
> (and Lisp).

I do not understand why you say that there is a relationship between the
"dynamic" language Scheme and an "open model".  I think such a
relationship doesn't exist.  There is at least one "closed model" OO
implementation which integrates nicely into scheme.

And if you take the module system into account, you'll end up with
a "closed model" anyway.  The module system must reject external
overrides for example.

Jost