On Mon, Jun 6, 2011 at 2:46 PM, David Bruant wrote:
> Le 06/06/2011 17:41, Mike Samuel a écrit :
> > 2011/6/6 David Bruant :
> >> The consequence of this second point is wondering whether it's a good
> idea
> >> to standardize WeakMap (instead of Map) at all.
> > Besides a lack of out-of-memory e
2011/6/6 David Bruant :
> Le 06/06/2011 17:41, Mike Samuel a écrit :
>> 2011/6/6 David Bruant :
>>> The consequence of this second point is wondering whether it's a good idea
>>> to standardize WeakMap (instead of Map) at all.
>> Besides a lack of out-of-memory errors and performance, a program
>>
Le 06/06/2011 17:41, Mike Samuel a écrit :
> 2011/6/6 David Bruant :
>> The consequence of this second point is wondering whether it's a good idea
>> to standardize WeakMap (instead of Map) at all.
> Besides a lack of out-of-memory errors and performance, a program
> using an object key map that do
2011/6/6 David Bruant :
> 2) The notion of weak reference as used in current WeakMap seems to be
> assuming that the garbage collector will work on whether objects are
> reachable or not. I have read (I thought it was the wikipedia page, but it
> apparently wasn't) that there is another notion for
Hi,
I'm currently working on the WeakMap documentation [1] and I have
thought of two points:
1) myWeakMap.set(key, value) doesn't return anything. It could return
the previous value for the key (if such a thing exists). Is it
intentional that the set function doesn't return anything?
2) The notio
On Jun 6, 2011, at 9:51 AM, David Dahl wrote:
> On 6/6/11 at 11:00,fra...@pwpconsult.com (Bill Frantz) wrote:
>> On 6/1/11 at 16:01, dd...@mozilla.com (David Dahl) wrote:
>
>>> The property is namespaced in order to provide future capabilities. The
>>> current design is asynchronous and looks li
Actually this is fixed in ToT WebKit, have closed the stale bug.
https://bugs.webkit.org/show_bug.cgi?id=56041
cheers,
G.
On Jun 5, 2011, at 5:04 PM, Juriy Zaytsev wrote:
>
>
> On Sun, Jun 5, 2011 at 5:30 PM, Brendan Eich wrote:
> On Jun 3, 2011, at 10:49 AM, Juriy Zaytsev wrote:
>
> > Chr
and another...
On Jun 6, 2011, at 11:44 AM, Allen Wirfs-Brock wrote:
> (correction copy function below)
> On Jun 6, 2011, at 10:58 AM, Allen Wirfs-Brock wrote:
>
>>
>> On Jun 5, 2011, at 7:50 PM, Christopher M. Balz wrote:
>>
>>> Are there proposals for fixing, without going as far as making a
(correction copy function below)
On Jun 6, 2011, at 10:58 AM, Allen Wirfs-Brock wrote:
>
> On Jun 5, 2011, at 7:50 PM, Christopher M. Balz wrote:
>
>> Are there proposals for fixing, without going as far as making a 'class'
>> system, the major drawback of prototype-based inheritance: Without s
On Jun 6, 2011, at 11:04 AM, Kam Kasravi wrote:
> Yes, I did read the rational and see why you put it first, though the
> cleanest IMHO is
> var o = {
>prototype : myProto,
>a:0,
>b: function () {}
> }
"prototype" is a valid property name that does not correspond to t
On Jun 6, 2011, at 10:32 AM, Brendan Eich wrote:
> On Jun 6, 2011, at 10:19 AM, Bob Nystrom wrote:
>
>> On Sun, Jun 5, 2011 at 9:35 PM, Peter Michaux wrote:
>> Based on my understanding of what the desugared code would be, the
>> last line above would be an error because Dragon.allMonsters is
>
Yes, I did read the rational and see why you put it first, though the cleanest
IMHO is
var o = {
prototype : myProto,
a:0,
b: function () {}
}
Or perhaps
var o = {
prototype = myProto,
a:0,
b: function () {}
}
Though I imagine the grammar impact for
On Jun 5, 2011, at 7:50 PM, Christopher M. Balz wrote:
> Are there proposals for fixing, without going as far as making a 'class'
> system, the major drawback of prototype-based inheritance: Without something
> like a JavaScript (js) class factory (a class factory as provided by most js
> fram
On Jun 6, 2011, at 10:19 AM, Bob Nystrom wrote:
> On Sun, Jun 5, 2011 at 9:35 PM, Peter Michaux wrote:
> Based on my understanding of what the desugared code would be, the
> last line above would be an error because Dragon.allMonsters is
> undefined.
>
> That's correct. Do you have any examples
On Jun 6, 2011, at 9:38 AM, Kam Kasravi wrote:
> I see, the object's prototype is to the left of <| and the actual object is
> to the right. I guess that was made clear in the proposal though I suspect
> others will invert the relationship since javascript programmers are used to
> defining th
On Sun, Jun 5, 2011 at 9:35 PM, Peter Michaux wrote:
> Based on my understanding of what the desugared code would be, the
> last line above would be an error because Dragon.allMonsters is
> undefined.
That's correct. Do you have any examples of code where inheriting the
constructor objects would
2011/6/6 Brendan Eich :
> Escapes are a pain, due to the double-backslash burden.
Yep. To fit into this kind of library, you could use a quasi syntax like
regexp`...`.ignoreSpaces().nonCapturingByDefault().build()
Not as pithy as flags, but extensible via
regexp.prototype.nonCapturingBy
On Jun 6, 2011, at 9:48 AM, Brendan Eich wrote:
> On Jun 6, 2011, at 9:38 AM, Kam Kasravi wrote:
>
>> I see, the object's prototype is to the left of <| and the actual object is
>> to the right. I guess that was made clear in the proposal though I suspect
>> others will invert the relationsh
Escapes are a pain, due to the double-backslash burden.
We really want quasis for this kind of extensibility. Quasis solve the
multiline problem too (I hope... :-).
/be
On Jun 6, 2011, at 9:52 AM, Mike Samuel wrote:
> 2011/6/3 Kyle Simpson :
>> I propose a /n flag for regular expressions, whic
2011/6/3 Kyle Simpson :
> I propose a /n flag for regular expressions, which would swap the default
> capturing/non-capturing behavior between ( ) and (?: ) operators (that is, (
> ) would not capture, and (?: ) would capture).
>
> The /n property would reflect on the RegExp object as `Noncapturing
- Original Message -
From: "Bill Frantz"
To: "David Dahl"
Cc: es-discuss@mozilla.org
Sent: Monday, June 6, 2011 11:00:29 AM
Subject: Re: Feedback and criticism wanted: DOMCrypt API proposal
On 6/1/11 at 16:01, dd...@mozilla.com (David Dahl) wrote:
>A JSON Object which labels the Key Pai
On Jun 6, 2011, at 9:38 AM, Kam Kasravi wrote:
> I see, the object's prototype is to the left of <| and the actual object is
> to the right. I guess that was made clear in the proposal though I suspect
> others will invert the relationship since javascript programmers are used to
> defining the
I see, the object's prototype is to the left of <| and the actual object is to
the right. I guess that was made clear in the proposal though I suspect others
will invert the relationship since javascript programmers are used to defining
the prototype after defining the object. The <| operator se
I updated http://wiki.ecmascript.org/doku.php?id=harmony:quasis based
on the feedback from the last meeting.
The demo testbed at
http://js-quasis-libraries-and-repl.googlecode.com/svn/trunk/index.html
is now up-to-date as well.
Changes listed at
http://wiki.ecmascript.org/doku.php?do=revisions&id
On 6/1/11 at 16:01, dd...@mozilla.com (David Dahl) wrote:
Hello JavaScript Enthusiasts,
I recently posted this draft spec (
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
In looking at this proposal, I am confused by:
cipherConfiguration
A JSON Object which labels the Ke
On Jun 6, 2011, at 2:31 AM, Kam Kasravi wrote:
> In the object literals proposal the following 2 examples are given below:
> var enhancedArrayProto = Array.prototype <| {
> do (func) {return this.foreach(func)},
> search (key {return this.indexOf(key) >= 0}
> };
> var myArray = en
On Sun, Jun 5, 2011 at 9:35 PM, Peter Michaux wrote:
> Are static members inherited? What happens in the last line of the
> following code?
>
>class Monster {
>static allMonsters = [];
>
>constructor() {
>Monster.allMonsters.push(this);
>}
>}
>
>clas
In the object literals proposal the following 2 examples are given below:
var enhancedArrayProto = Array.prototype <| {
do (func) {return this.foreach(func)},
search (key {return this.indexOf(key) >= 0}
};
var myArray = enhancedArrayProto <| [0,1,2,3,4,5];
1. I believe search is mis
On Jun 5, 2011, at 10:59 PM, Kam Kasravi wrote:
> From the harmony classes example copied below for reference.
> The set health(value) {...} assigns a new value to this.health. But health is
> a private property, so the assignment is setting a public property. Shouldn't
> the assignment be priva
29 matches
Mail list logo
