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

Comments

This page is part of the web mail archives of SRFI 20 from before July 7th, 2015. The new archives for SRFI 20 contain all messages, not just those from before July 7th, 2015.



> 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