es-discuss Digest, Vol 43, Issue 7

Mark S. Miller erights at google.com
Sat Sep 4 07:03:47 PDT 2010


To make my previous too-abstract answer more concrete, let's examine the
specific example you raise:

On Fri, Sep 3, 2010 at 6:04 PM, Leo Meyerovich <lmeyerov at gmail.com> wrote:

> For example, it could answer why the ability to check whether an object has
> been collected is not an overt channel that is part of getting a reference:
> if you don't want somebody to check, don't give them the object.
>

Ok, let's suppose that we consider a semantics in which a shared object
reference is an overt communications channel. Overt implies that correct
programs may rely on this communications channel. This semantics introduces
a non-modularity, in that providing an abstraction to two clients enables
those clients to legitimately interact in ways out of control of their
shared abstraction. Going back to Parnas, modularity is supposed to enable
us to make a greater range of semantically-incremental changes in a
syntactically local manner. If these clients were later given separate
instances, as separate facets of the same shared abstraction, that would
cause surprising breakage.

How would we program modularly in such a system? We would need to avoid ever
sharing references except when we intend to enable communication. Every
operation that today would cause reference sharing would instead have to
mint and hand out a new facet to each new client. We would no longer be able
to share data structures, as the shared references within these structures
would be overt but unintended communications channels. We would effectively
have to partition the heap into disjoint subheaps, where all communications
between them copies all object being passed.

In short, the language we'd get would resemble ES3, in which modular
programming was impossible because all shared user-defined objects were
mutable. The only protection mechanism we'd have would be like postMessage
between iframes (without the previously suggested optimization), which is
fine for some problems but not a practical way to compose libraries. By
introducing Object.freeze, we fixed all this.


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100904/2545547a/attachment.html>


More information about the es-discuss mailing list