On Tue, Nov 8, 2011 at 12:50 PM, Andreas Rossberg <rossb...@google.com>wrote:
> On 8 November 2011 20:46, Mark S. Miller <erig...@google.com> wrote:
> > Nevertheless, I see your point. Many defensive ES5 abstractions will be
> less
> > defensive than this. If I understand you correctly, your point is
> > specifically about the [[Call]] and [[Construct]] traps.
>
> Yes. Existing code has no reason to bother making functions
> non-extensible if all it does is calling them. Proxy.attach
> fundamentally breaks that (so far correct, AFAICT) assumption.
>
I think we're agreeing on the operational point -- that much defensive code
won't bother to freeze such functions. But for clarity, I must correct your
"no reason". The reason is one of the oldest software engineering best
practices: Say What You Mean. Perhaps a clearer statement is Mean Only What
You Say. The "it" in your above sentence presumes a non-local whole program
analysis which violates this rule, and is in any case inapplicable to
libraries.
To keep what the program means in sync with what it seems to mean, we need
to avoid introducing unexpressed communication channels. Or, put another
way, unexpressed shared mutable locations. If Alice provides object C to
both B and D, the only ways in which this should enable further
communication between B and D (beyond that which they may have already had)
should be according to the expressed behavior of C. For example, if the
expressed behavior of C is completely stateless, then the fact that B and D
both share a reference to C should not enable any additional
communications/interaction/influence between B and D.
These constraints are useful for much beyond security. If you wish to
program in a mostly functional style, you'd like the deviations from
functional style to only be where you've made a purposeful choice. When
debugging, you need to figure out: How did the bad symptom happen? If you
can bound the possible causes, by reasoning in terms of the program's
intended behavior, your detective work is much easier.
"A program should not only work. It should also appear to work." --Carl
Hewitt.
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
