I am unclear from this proposal. What would happen if I declared the
same module twice? Would it reopen the module and add the extra
declarations?
-Charles
On May 16, 2010, at 11:11 AM, Brendan Eich wrote:
On May 16, 2010, at 9:32 AM, Dmitry A. Soshnikov wrote:
On 15.05.2010 19:22, B
/doku.php?id=strawman:weak_references
>
> Cheers,
> Tom
>
> On Thu, Dec 10, 2009 at 9:44 AM, Charles Jolley wrote:
> Hi,
>
> I was wondering if any thought has gone into adding weak references and
> destructors to Harmony.
>
> We are finding that as we build large, long runni
Hi,
I was wondering if any thought has gone into adding weak references and
destructors to Harmony.
We are finding that as we build large, long running JS apps, it is very hard to
keep memory under control using the built-in GC since any reference - even for
caching - will prevent the memory
Why? What would the hypothetical Data.prototype.freeze do that would
be
different to applying Object.freeze to a Data object?
For example, I might load an immutable JPG and then want to set:
imageData.name = "someimage.jpg";
to help me keep track of what the data is. Freezing would prevent
on it?
Regards,
Maciej
On Nov 5, 2009, at 4:01 PM, David-Sarah Hopwood wrote:
Charles Jolley wrote:
This looks like a good approach. I wonder if the Data/DataBuilder
distinction could be handled better by using the Object.freeze()
semantics. Even if the browser does not support freezing in
This looks like a good approach. I wonder if the Data/DataBuilder
distinction could be handled better by using the Object.freeze()
semantics. Even if the browser does not support freezing in the
general sense yet, you could borrow the ideas for data.
Probably the wrong API names, but here
Hi,
Sorry if this has been covered already, but I'm curious if this list
has considered something like co-routines for a future version of ES.
An example implementation of the concept (I'm not sure of the quality)
is here:
http://www.xucia.com/strands-doc/index.html
Properly implemented
You can tell me why this module design relies on eval'ing a string?
It would be nice to be able to pass a Function object also.
I wonder if that might be better for performance also as an optimized
implementation could potentially avoid re-parsing the JS. [Note: I
haven't implemented this
, at 4:22 PM, Charles Jolley wrote:
Not sure how you can assume the latter from the former:
if (! function() { "use strict"; return this; }()) {
"use strict";
/* I'm an ES5 browser and DEFINITELY in strict mode now; doesn't
matter what came before me... */
}
Not sure how you can assume the latter from the former:
if (! function() { "use strict"; return this; }()) {
"use strict";
/* I'm an ES5 browser and DEFINITELY in strict mode now; doesn't
matter what came before me... */
}
___
es-discuss mailin
These are certainly idioms, especially the first test (as in "kick
the bucket", something an ES3 programmer could not understand based
on the terms in the code alone, only by also reading the ES5 spec or
a book based on it). Do they deserve sugar?
To me this would be something that should b
ClassB = ClassA.extend({
foo: function method() {
(IS_ES5_STRICT ? method : arguments.callee).base.apply(this,
arguments);
}
});
But why wouldn't you use method always? Or callee, as Ollie
suggested. Agree it's annoying to have to add six letters of cruft
after the function keyword (w
But we can hear feedback, esp. on this list, about hardship adopting
strict mode in early ES5 implementations. Mozilla's will be done
shortly, and it sounds like WebKit's is coming along quickly too.
Feedback based on two interoperable implementations in developers'
hands before the ES5 spe
I thought the point of
"use strict" is the same code could still run on older browsers who
don't understand the directive.
-Charles
We talked about this issue yesterday at the end of the TC39 meeting.
I think Allen had to leave but I mailed him about it.
/be
Best
In general I think this particular approach is not developer
friendly enough.
The function expression name is fairly irrelevant, so you could have
a standard style guideline
foo : function callee() {
callee.base.apply ...
}
This is actually a really interesting idea. I'll try to use
Given your example, a named function expression would do the job
trivially:
ClassB = ClassA.extend({
foo: function foo() {
foo.base.apply(this, arguments); // calls super!
// other code
}
});
This works but, as I said, this approach has a couple of drawbacks:
1. The function ha
Hi everyone,
First an introduction: I am the lead developer of SproutCore (http://www.sproutcore.com
), an open source framework for building client-side applications in
HTML5. SproutCore is used in several large projects including Apple's
MobileMe and iwork.com, OtherInbox, and some other
17 matches
Mail list logo
