(n.b. Peter responded to me privately. I'm assuming he meant to cc
the list in his reply to me. Accordingly I have not removed any part
of his response, and replied inline below.)
On Aug 13, 2008, at 9:57 PM, Peter Michaux wrote:
On Wed, Aug 13, 2008 at 8:45 PM, Neil Mix [EMAIL PROTECTED
On Aug 13, 2008, at 11:44 PM, Brendan Eich wrote:
I've written that interoperation problems could result if different
browsers used different degrees of conservatism and partial
evaluation, but I don't expect static checker extensions in most
browsers, and I'm also not too worried
On Aug 14, 2008, at 12:30 PM, Brendan Eich wrote:
I took Neil's point to favor not only a separate lint-like tool
(which some find painful to procure and remember to run), but
possibly something like Cormac's idea I mentioned a few messages
ago: a type checker that runs when the code
On Aug 13, 2008, at 8:02 PM, Peter Michaux wrote:
Are these
type-related features what the community of ECMAScript 3 programmers
were really asking for emphatically years ago? Is the community really
asking for now with the surge of functional programming?
One hacker's opinion: Yes,
On Jul 19, 2008, at 12:25 AM, Brendan Eich wrote:
* ES3.1 and ES4 will both allow ‘function’ inside control flow
statements [directly inside an explicit block, not as the lone
unbraced consequent statement of an if, while, etc. /be], and it
will be hoisted to the top of the block and
On Apr 7, 2008, at 10:37 AM, Steven Johnson wrote:
Dynamic classes also incur nontrivial overhead in memory use and
runtime
performance. IMHO we'd want a fairly compelling argument for making
all
classes dynamic by default.
It would probably put an end to the acrimony about ES4 being
On Mar 30, 2008, at 12:58 PM, Jason Orendorff wrote:
Here's a brief case: generators let you factor a complex loop,
dividing the value-producing part from the value-consuming part.
Neither part has to be transformed in a non-obvious way. With
iterators alone, you do this by rewriting the
I think this is the specific point of disagreement. Complexity in a
language
does not necessarily reduce the complexity of programs. I think the
opposite may
be truer. The difficulties we have had in the development community
since 1999
were not due to over-minimization. They were due
On Mar 13, 2008, at 11:47 AM, Lars Hansen wrote:
function __createProperty__(name:EnumerableId,
dontEnum:boolean=false,
dontDelete:boolean=false,
readOnly:boolean=false): void
I like where this is going.
On Mar 11, 2008, at 5:16 PM, Kris Zyp wrote:
Declarative is nice, but as mentioned before, it ignores one of the
primary
use cases: addition of non-enumerable properties to built-ins (by
libraries,
primarily).
I've read mention of the weirdness of the timing window between the
But why won't we feel it, as trace-readers, just as much when the
PTCs were explicit? This, I don't follow. The programmer and the
debugger-driver are often very different people, in general skills,
familiarity with the source at hand, etc.
We will, but the point is: you (or someone you
Its probably important to go back to Brendan's point about this
being a
feature and not an optimization. Even in Java the stack traces
you get
are very distantly related to the actual code running when all the
inlining, escape analysis, and traditional optimizations are applied.
They
Others argue that this syntactic penalty box means no one will use
PTC; the cursed view of tail calls and recursion will not fade away.
Interesting -- I'd love to know more about why that is. Dave
Herman's example in the ticket isn't so bad once the annotation is
placed on the function
I think this is what Garrett is referring to:
js function f() {}
js f.prototype.foo = blah;
blah
js var x = new f();
js print(x.propertyIsEnumerable(foo));
false
js for (var n in x) print(n);
foo
And I have to agree with him, the method is confusing. Based on its
name, I'd expect it to return
14 matches
Mail list logo
