Denys Duchier wrote:
>
> pvr@info.ucl.ac.be (Peter Van Roy) writes:
>
> > b. The 'object feature' concept is broken. Why should an object have
> > encapsulated stateful attributes and public stateless features? In our
> > view, the existing features should be removed and replaced by
> > encapsulated stateless features. I.e., remove features and add stateless
> > attributes.
>
> (...)
>
> However object features have their place too, and it seems to me that
> removing them would be a straight loss with no real gain (plus it
> would break backward compatibility).
I agree with you about the backward compatibility issue. However, I
don't really understand why objects look like a mix between procedures
(for methods) and records (for features). The latter looks unnecessary
(you can always write a method that returns a stateless member). We
often claim here that objects are simply procedures encapsulating a
state, which is nice semantically, but this is not true in practice.
The drawback is: you cannot transparently encapsulate an object inside a
procedure.
The encapsulation of objects inside procedures allows to make an object
active (all method calls are sequentialized) without breaking its class
definition. We use similar constructs for making distributed objects
stationary. I have no way to make this generic and fully transparent if
the object has features.
fun {MakeActive Obj}
S P={NewPort S}
in
thread {ForAll S Obj} end
proc {$ Method} {Send P Method} end
end
-- Raphaël Collet - raph@info.ucl.ac.be - http://www.info.ucl.ac.be/~raph/ - Please send submissions to hackers@mozart-oz.org and administriva mail to hackers-request@mozart-oz.org. The Mozart Oz web site is at http://www.mozart-oz.org/.