Re: closures for GOOPS privates

[Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>]

Clark McGrew <mcgrew@ale.physics.sunysb.edu> writes:

> (define-generic a-b)
> (define-generic a!)
> (define-generic b!)
> (define <a-b>
>    (let ((local-a (make-accessor 'a))
>          (local-b (make-accessor 'b)))
>      (define-method a-b ((obj <a-b>) (- (a obj) (b obj)))
>      (define-method a! ((obj <a-b>) (v <number>)) (set! (a obj) v))
>      (define-method b! ((obj <a-b>) (v <number>)) (set! (b obj) v))
>      (class ()
>        (local-a #:accessor a #init-value 1)
>        (local-b #:accessor b #init-value 2))))
> 
> This means that goops does have data hiding independent of any module
> system.  That is great.  I guess the data can still be reached with
> slot-ref, but who cares...


I don't see the difference to Mikaels example.

Mikael said that it is possible to handle data hiding
as long as you keep the data accessors separate.

The problem with this solution is that you can't put the related
classes "bike" and "piano" (yes, yes, it's a silly example but I don't
have some nice eiffel examples here) and the class "piano-bike" 
into a single module.  

Althought all you want is to make the class "piano-bike" (I really have
to find a better example) available to your customers you must also
publish the internal classes "piano" and "bike" because you can't put
them into a single module.


That's why I will implement two solutions by the end of next month: a)
The module /has/ one or more classes (which seems to be the preferred
solution at the moment and is also easy to implement) and b) the
module /is a/ class (my preferred solution and also the right thing
(TM) to do :>).


Jost