Operator overloading revisited

[Mark S. Miller]

On Mon, Jul 6, 2009 at 6:10 PM, Alex Russell<alex at dojotoolkit.org> wrote:
>>> The original "classes as sugar" sketch Mark did to general agreement at
>>> Oslo
>>> included freezing the class object (constructor function) *and* bind the
>>> class name as a const (neither writable nor configurable in the binding
>>> object or frame).
>
> This point disturbs me. Making classes frozen solves no existing JS
> programmer problems, introduces new restrictions with no mind paid to the
> current (useful) patterns of WRT the prototype chain, and introduces the
> need for a const that only seems there to make some weird security use-cases
> work.
> [...]
> Questions of "integrity" here to my mind should be justified by why they'll
> be good for ALL code, not just abuse of built-ins, and then weighed against
> other possible solutions. Freezing classes seems premature to me.


For low integrity patterns (or "loosey goosey" as Allen sometimes
says), JavaScript has always been and will remain a fine language. In
ES5 for the first time, it is possible to engage in high integrity
patterns; but it is not easy. We don't need syntactic sugar to provide
yet another way to express what can already be expressed easily. It is
when something valuable becomes possible, but can't be made easy
without syntactic sugar -- like high integrity programming in ES5 --
that syntactic sugar may be justified.

So no, it doesn't need to be justified for all code. It just needs to
be justified by code that isn't well served by ES5 as it is. No one is
proposing removing JavaScript's support for making low integrity
programming easy.

As for whether high integrity is only of interest to security weirdos,
I'll just remind everyone that the notion of objects [Simula,
Smalltalk, Actors] -- or similarly abstract data types [Clu] -- was
conceived from the beginning as: reusable packages of encapsulated
state together with the code responsible for maintaining that state's
invariants and presenting an abstract interface. That interface that
quickly came to be characterized in terms of pre-conditions and
post-conditions [Liskov].

Virtually none of the systems or literature that brought about this
revolution was concerned with security per se. These notions were
created for the sake of modularity, abstraction, and flexible
composability. None of these concerns have gone away; hence the
frequent complaint that JavaScript today provides inadequate support
for serious large scale programming -- a need which classes-as-sugar
hopes to address.

Finally, I make no apology for being a security weirdo or for wanting
to see JavaScript become more securable. JavaScript is uniquely
positioned as the fastest growing portion of many organizations'
attack surface; and often also their weakest link. This is a role for
which it was not designed and for which it has been ill suited. By the
same token, JavaScript is also uniquely positioned to capitalize on
prior work on programming language security. It's continued evolution
should indeed be shaped by the unique niche it occupies.

-- 
    Cheers,
    --MarkM