Spam detection software, running on the system "nibbler.dojotoolkit.com", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
postmaster for details.
Content preview: On Jul 6, 2009, at 7:23 PM, Mark S. Miller wrote: > On Mon,
Jul 6, 2009 at 6:10 PM, Alex Russell<[email protected]> > 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. [...]
Content analysis details: (5.0 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS
4.4 HELO_DYNAMIC_IPADDR2 Relay HELO'd using suspicious hostname (IP addr
2)
0.6 FH_HELO_EQ_D_D_D_D Helo is d-d-d-d
2.3 TVD_RCVD_IP TVD_RCVD_IP
-2.3 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
[score: 0.0000]
--- Begin Message ---
On Jul 6, 2009, at 7:23 PM, Mark S. Miller wrote:
On Mon, Jul 6, 2009 at 6:10 PM, Alex Russell<[email protected]>
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.
/me scrapes jaw from floor
JS may have many fine "loosey goosey" primities, but it's not a "fine"
language for dynamic programming (yet). It's only a plausibly OK
language that allows you to (at great expense) build your own tools up
from the (ample and useful) raw materials that populate the landscape.
It is not, however, simple to communicate the meaning of many of the
discovered patterns, use them to construct larger-scale constructs, or
treat them as a stable baseline from which to work.
Suggestions that JS is just fine for what people are using it for
today but insufficient to handle some laudible but unapproachable
class of tasks by dint of its looseness strike me a disingenuous. Why
should the "high integrity" programs get to annex the new keywords and
constructs for their own with little or no improvements to the main-
line tasks which have been so painfully executed for years?
Your null hypothesis is broken.
In
ES5 for the first time, it is possible to engage in high integrity
patterns; but it is not easy.
Welcome to the club!
We don't need syntactic sugar to provide
yet another way to express what can already be expressed easily.
Yes, yes we do.
In part we need them because "expressed easily" isn't the whole story.
It says "I, a person of above average means, can see a way through
this problem which can be communicated to others of above average
means who have trudged through the same semantic desert and arrived at
this shore with me". Blarg. What's being proposed is not an
improvement in the ability of JavaScript programmers to communicate to
other programmers (who may be in more of a hurry) as to what their
programs are supposed to mean.
If the point of introducing classes isn't to make the common case
easier, simpler to read, and more efficient....well, then I'm not sure
why everyone is spending so much time on this. There are plenty of
fine little research languages that can use the love.
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.
Indeed! That does not imply a pre-judgement as to the relative merit,
programmer cost, or usability price for such sugar vs. other uses of
the language, though.
High-integrity is not the common case, so it deserves worse huffmann
codings. The (unadorned) word "class" should be reserved for efforts
that benefit the common case, while modifiers to it should indiciate
the special case. How 'bouts:
class(frozen) Foo {
}
Or for the syntax loving amongst us:
frozen class Foo {
}
New keyword? You bet. But this is something that's turned on by a new
mode to start with, right?
So no, it doesn't need to be justified for all code.
It's weighting sure does. You can't just duck the charge on this by
saying the feature is important. HOW important relative to other (more
popular) uses of the language matters.
More to the point, why does this problem need to be solved in the
language, anyway? Isn't it something that is more of a "platform"
issue...i.e., something we can be asking browsers to help us out with?
That, or we could bring Workers into the scope of the language and
expand the standard library in directions that it probably should go
anyway.
Not everything needs syntax. Not even everything new.
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 did not call those with an interest in the security of the platform
weirdos. I suggested that with regards to the big problems that the
largest bodies of JS code face today, security barely makes the list.
Now, with regards to the web platform as a whole, I'll buy the
argument that it's both underserved and pressing. But not at the JS
language level.
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.
I support most of those goals = )
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.
There's no quarrel with "classes-as-sugar" from me. Only the
requirement that they be frozen by default.
Finally, I make no apology for being a security weirdo or for wanting
to see JavaScript become more securable.
Nor should you. As we discussed in person, I empathize with your
concerns and appreciate the approach you're taking.
JavaScript is uniquely
positioned as the fastest growing portion of many organizations'
attack surface; and often also their weakest link.
I reject that. I'll accept this, though:
Web applications are uniquely positioned
as the fastest growing portion of many
organizations' attack surface; and often
also their weakest link. JavaScript plays
a part in most compromises, but these are
enabled primarily by a lack of platform
awareness of ambient authority granted
to objects originated by naive domains.
Implicating JavaScript as a language in this situation seems unfair to
me when the original (and permeating) sins were committed elsewhere.
Further, I distrust language-level fixes for what is a platform
problem since they're hard to reason about and encourage too much fine-
grained coordination for my comfort.
Regards
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
--- End Message ---
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
