Re: Security Demands Simplicity (was: Private Slots)
Domenic Denicola wrote:
If we’re making up new syntax, I think this would be much nicer if
“private.x” were spelled “this.@x” and “private(x)” were spelled “x.@”
+1 and this is not a minor point.
Also, I don’t see why constructors need to use the “private.x” syntax
whereas other methods get to use the free variable?
+2 -- Same here, only moreso!
This thread goes over ground well-trod in 2011:
https://mail.mozilla.org/pipermail/es-discuss/2011-July/015787.html
and others -- search for private data record 2011 es-discuss
site:mail.mozilla.org.
With these in mind I give the following fork:
https://gist.github.com/4562796
Kevin, could you do an alterna-gist as Domenic proposes? Of course
there's much more at stake than syntax, but it would help.
/be
*From:*es-discuss-boun...@mozilla.org
[mailto:es-discuss-boun...@mozilla.org] *On Behalf Of *Kevin Smith
*Sent:* Thursday, January 17, 2013 21:40
*To:* Mark S. Miller
*Cc:* Brendan Eich; es-discuss
*Subject:* Re: Security Demands Simplicity (was: Private Slots)
It seems as if this approach to private class members also allows us
to describe private methods in a convenient way. Private methods can
be attached to the _prototype_ of the private field object, thus
avoiding per-instance allocation. Of course, the correct this value
has to be used in the expansion when calling the private method, but
this approach appears to be compatible with mixins (whereas private
symbols are not).
https://gist.github.com/4561871
Thoughts?
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Polyfill for Maps and Sets
Thaddee Tyl wrote: On Thu, Jan 17, 2013 at 8:12 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Dude, do you even read the spec? http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.14.5.4 So this is just the wiki lacking some updates? http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets Yes. The wiki will lag the spec. I think it may pay to update the wiki, but it's unlikely everyone will do this diligently (cc'ing rwaldron in case he is motivated in this forEach case). So: always check Allen's latest draft. It trumps the wiki, unless there's a bug (and it may be hard to know without reading es-discuss or just asking here, cc'ing Allen). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Security Demands Simplicity (was: Private Slots)
I've been stewing on this some more, and I realized something potentially
very interesting. If we use weakmaps in the manner specified by Kevin (with
Mark's help), I think we've very nearly added nominal typing to classes.
Assuming this privacy behavior was tied to classes, and assuming only
members of the class could be added to the weakmap, and assuming that *all*
members of the class belonged to the weakmap, the weakmap would quite
literally be the set of all members of that class (type). If there was an
easy way of asking the weakmap if an object belonged to the it, it would
the same as asking if the object was an instance of that class in a very
strong, nominal way. I guess I think this could be a plus, because it
allows for nominal types to be tied to classes, and yet do it in a very
javascripty feeling way.
Thoughts?
- Russ
On Fri, Jan 18, 2013 at 4:25 AM, Brendan Eich bren...@mozilla.com wrote:
Domenic Denicola wrote:
If we’re making up new syntax, I think this would be much nicer if
“private.x” were spelled “this.@x” and “private(x)” were spelled “x.@”
+1 and this is not a minor point.
Also, I don’t see why constructors need to use the “private.x” syntax
whereas other methods get to use the free variable?
+2 -- Same here, only moreso!
This thread goes over ground well-trod in 2011:
https://mail.mozilla.org/**pipermail/es-discuss/2011-**July/015787.htmlhttps://mail.mozilla.org/pipermail/es-discuss/2011-July/015787.html
and others -- search for private data record 2011 es-discuss site:
mail.mozilla.org.
With these in mind I give the following fork: https://gist.github.com/**
4562796 https://gist.github.com/4562796
Kevin, could you do an alterna-gist as Domenic proposes? Of course there's
much more at stake than syntax, but it would help.
/be
*From:*es-discuss-bounces@**mozilla.org
es-discuss-boun...@mozilla.org[mailto:
es-discuss-bounces@**mozilla.org es-discuss-boun...@mozilla.org] *On
Behalf Of *Kevin Smith
*Sent:* Thursday, January 17, 2013 21:40
*To:* Mark S. Miller
*Cc:* Brendan Eich; es-discuss
*Subject:* Re: Security Demands Simplicity (was: Private Slots)
It seems as if this approach to private class members also allows us to
describe private methods in a convenient way. Private methods can be
attached to the _prototype_ of the private field object, thus avoiding
per-instance allocation. Of course, the correct this value has to be
used in the expansion when calling the private method, but this approach
appears to be compatible with mixins (whereas private symbols are not).
https://gist.github.com/**4561871 https://gist.github.com/4561871
Thoughts?
{ Kevin }
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Private symbols as WeakMap sugar
On 17 January 2013 21:08, Brendan Eich bren...@mozilla.com wrote: Andreas Rossberg wrote: Actually, I don't see why this should have a measurable impact on performance in practice. The generic case is dog-slow for JavaScript anyway, what matters is how easy it is to specialise for the types actually seen at runtime. And there, this would just add yet another row to the (already complex) matrix of cases for receiver/index type pairs that you optimize for. The same might actually be true for symbols, depending on the implementation strategy. Probably I'm more sensitive to the generic case, which while dog slow still dogs some real-world critical paths (if not fake/lame/old benchmarks). It all costs, David is proposing yet another cost. Maybe that's my final answer :-|. I don't know enough about the internals of other VMs, but at least in V8, the generic case will jump into the C++ runtime (costly) and potentially trickle through hundreds of lines of logic. I think you will have a very hard time constructing even a highly artificial benchmark with which one additional conditional in that logic would be measurable. Obviously, that doesn't imply that I consider it a good idea... ;) Like any new type or representation, it may cause deoptimization and increased polymorphism, but that's nothing new under the sun, and we are adding plenty of that with ES6. In contrast, private symbols (any symbols, public/unique or private) should benefit from existing property-in-receiver optimizations. Right? Perhaps, perhaps not. For V8, we haven't really thought hard yet about how they fit into the existing representation. They may still end up requiring a case distinction somewhere. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Security Demands Simplicity (was: Private Slots)
Le 18/01/2013 06:47, Russell Leggett a écrit :
On Thu, Jan 17, 2013 at 9:40 PM, Kevin Smith khs4...@gmail.com
mailto:khs4...@gmail.com wrote:
It seems as if this approach to private class members also allows
us to describe private methods in a convenient way. Private
methods can be attached to the _prototype_ of the private field
object, thus avoiding per-instance allocation. Of course, the
correct this value has to be used in the expansion when calling
the private method, but this approach appears to be compatible
with mixins (whereas private symbols are not).
https://gist.github.com/4561871
Thoughts?
I've been on the fence with the debate, but I'll admit that this
proposal is really winning me over. I don't know if it's too late to
get this syntax in, but it would be a major win for me.
syntax details aside (especially with Domenic improvements), I agree.
I like this a lot more than private symbols.
Assuming the only valid use case for private symbols is classes, I agree
It actually feels a lot like deconstructing an abstract data type or
pattern matching a case class in scala. There is something nice about
keeping all that extra stuff off the actual object. I'm not sure if
I'd still like it as much without the syntax, but maybe I would now.
I have do have a few questions on this, though:
1. How does this interact with proxies? I'm guessing that a proxy will
not map correctly and therefore make it inaccessible. Personally, I'm
ok with that.
It does not interact that well because of the this-binding. Classes have
been long expected, so will be used, so proxies have to work well with them.
class Purse {
private balance;
constructor(balance = 0) {
private.balance = balance;
}
getBalance() { return balance; }
}
var p = new Purse(6);
var pp = new Proxy(p, {});
console.log(pp.getBalance());
We should be able to expect p and pp to act the same in all
circumstances. With Kevin's expansion, pp.getBalance() throws a
TypeError, because amp.get(this) is not an object.
Proxy authors can work around that by returning functions bound to the
target, but this is not free obviously (create as much bound functions
as there are of (instance, method) pair).
The interaction between private syntax and proxies has the following
components:
1) Do the proxy and the target act the same regarding private properties?
The answer is yes with whitelisted private symbols, no with naive
weakmap-expanded private syntax (I explain non-naive below)
I think the answer should be yes here.
2) Does the proxy has a word to say about the access to the private
property?
It's yes with private symbols (different trap if whitelisted or not).
The answer is yes for weakmap-expanded private syntax, but with some
explanation. The proxy can't know about the private property, however,
every access to something private has to be performed through something
public (public accessor or method). Indeed, the class encapsulate access
to private state (this isn't true of private symbols in general). Since
the proxy can cut communication of public accesses, it can also cut
accesses to private properties. I think that this additional simplicity
weighs in favor of the removal of private symbols.
(I had a third point in mind and I forgot it...)
Above I've talked about naive weakmap-expanded private syntax. A less
naive version could override the Proxy constructor to know about proxy
- target associations. Access to private state wouldn't start with the
naive amp.get(this), but rather with amp.get(proxyToFinalTarget(this)
|| this). (finalTarget in case the target of the proxy is itself a
proxy).
For native syntax, we can imagine this setup exists before any code
runs. The transpiler story is a bit less clear to me. I see different
ways of writing class transpilers with different properties:
1) make classes incompatible with proxies
2) share (aka leak) the proxyToFinalTarget function to transpiled classes
3) bring the full transpiler in the runtime so that classes can work
with proxies (only the transpiler has access to proxyToFinalTarget)
I think different users in different contexts all have a solution to
their need.
2. Can I use private as a normal variable? Can it be bound to a new
variable, passed as an argument, or returned from a function?
constructor(balance = 0) {
let p = private;
p.checkNum(amount);
p.balance = balance;
}
I would understand not going this route, but it definitely restricts
access very tightly where private member or manually using a weakmap
would allow it. Perhaps that edge case can just be handled by falling
back to manually using a weakmap.
Mark's point about private symbol being mostly useful in the context of
class convinced me that pretty much every other context can work with
WeakMaps.
No opinion on your third point.
David
Re: Security Demands Simplicity (was: Private Slots)
Kevin, could you do an alterna-gist as Domenic proposes? Of course there's
much more at stake than syntax, but it would help.
I've updated my gist to clarify Domenic's second point, but I'll let him
maintain his fork for the @ syntax variation.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Security Demands Simplicity (was: Private Slots)
I've been stewing on this some more, and I realized something potentially
very interesting. If we use weakmaps in the manner specified by Kevin (with
Mark's help),
Um, that should be Mark (with Kevin's itty-bitty help). : )
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proxy target as __proto__? (Re: Proxy's optional target)
Hi Claus, I'm not sure I fully understand your proposal, but could you not achieve it by simply doing: var target = ...; // might be frozen var p = Proxy( Object.create(target), handler); ? Cheers, Tom 2013/1/17 Claus Reinke claus.rei...@talk21.com The proxy target is important because it specifies some invariants about the proxy (typeof, builtin brand, behavior of forwarding for unspecified traps, values of internal properties like [[DateValue]], [[NumberValue]], etc.). That is probably the most important difference between direct proxies and old-style proxies. Yet I find it slightly limiting and accident-prone: it uses invariants and target to make proxies not just behave like an object, but to behave like the target. Presentations on direct proxies tend to present too usage patterns: wrapped objects and virtual objects. My problem is: if I am using proxies as wrappers, I want to use the target object as a -wait for it- prototype, to be *modified* by the proxy. But if the target object happens to be frozen, modified returns are no longer allowed by the invariants. To cover this eventuality, I should use the virtual object pattern even if I just want to wrap an object! Would it be possible/helpful to use the target merely as a __proto__ instead of a harness, inheriting the target's internal properties without over-constraining the proxy's ability to modify the wrapped target's behavior? Invariants could still use an implied object for freezing the *proxy*, so the proxy would behave as an object, not necessarily the same as the target object. Claus __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Polyfill for Maps and Sets
It doesn't seem reasonable to maintain two versions of the proposals as they become specifications. My first thought is that the simplest possible strategy is to update harmony proposal pages (on the wiki) with a line at the top that indicates that the proposal is now in the spec draft. This is low effort-cost to convey that everyone should be looking at the latest and greatest of each proposal as they become part of the ES6 draft revisions and progress towards finalization therein. Rick On Fri, Jan 18, 2013 at 4:38 AM, Brendan Eich bren...@mozilla.com wrote: Thaddee Tyl wrote: On Thu, Jan 17, 2013 at 8:12 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Dude, do you even read the spec? http://people.mozilla.org/~**jorendorff/es6-draft.html#sec-**15.14.5.4http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.14.5.4 So this is just the wiki lacking some updates? http://wiki.ecmascript.org/**doku.php?id=harmony:simple_**maps_and_setshttp://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets Yes. The wiki will lag the spec. I think it may pay to update the wiki, but it's unlikely everyone will do this diligently (cc'ing rwaldron in case he is motivated in this forEach case). So: always check Allen's latest draft. It trumps the wiki, unless there's a bug (and it may be hard to know without reading es-discuss or just asking here, cc'ing Allen). /be __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Wiki and drafts (was: Polyfill for Maps and Sets)
Le 18/01/2013 18:58, Rick Waldron a écrit : It doesn't seem reasonable to maintain two versions of the proposals as they become specifications. My first thought is that the simplest possible strategy is to update harmony proposal pages (on the wiki) with a line at the top that indicates that the proposal is now in the spec draft. This is low effort-cost to convey that everyone should be looking at the latest and greatest of each proposal as they become part of the ES6 draft revisions and progress towards finalization therein. I fully agree. It'll bring more attention to what happens in the drafts and will make more people to review them. Also, if something in the harmony namespace is put on hold like harmony:classes it should probably be downgraded to the strawman namespace. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Polyfill for Maps and Sets
As it turns out, my suggestion above had already been used (at least) once before—Allen marked the destructuring proposal similarly. I've gone ahead and updated the following: http://wiki.ecmascript.org/doku.php?id=harmony:spread http://wiki.ecmascript.org/doku.php?id=harmony:rest_parameters http://wiki.ecmascript.org/doku.php?id=harmony:destructuring http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax http://wiki.ecmascript.org/doku.php?id=harmony:iterators http://wiki.ecmascript.org/doku.php?id=harmony:generators http://wiki.ecmascript.org/doku.php?id=harmony:generator_expressions http://wiki.ecmascript.org/doku.php?id=harmony:array_comprehensions http://wiki.ecmascript.org/doku.php?id=harmony:object_literals http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes http://wiki.ecmascript.org/doku.php?id=harmony:quasis ...to all reflect the same consistent message and linkage to the draft spec and bugzilla pages. Rick On Fri, Jan 18, 2013 at 12:58 PM, Rick Waldron waldron.r...@gmail.comwrote: It doesn't seem reasonable to maintain two versions of the proposals as they become specifications. My first thought is that the simplest possible strategy is to update harmony proposal pages (on the wiki) with a line at the top that indicates that the proposal is now in the spec draft. This is low effort-cost to convey that everyone should be looking at the latest and greatest of each proposal as they become part of the ES6 draft revisions and progress towards finalization therein. Rick On Fri, Jan 18, 2013 at 4:38 AM, Brendan Eich bren...@mozilla.com wrote: Thaddee Tyl wrote: On Thu, Jan 17, 2013 at 8:12 PM, Domenic Denicola dome...@domenicdenicola.com wrote: Dude, do you even read the spec? http://people.mozilla.org/~**jorendorff/es6-draft.html#sec-**15.14.5.4http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.14.5.4 So this is just the wiki lacking some updates? http://wiki.ecmascript.org/**doku.php?id=harmony:simple_**maps_and_setshttp://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets Yes. The wiki will lag the spec. I think it may pay to update the wiki, but it's unlikely everyone will do this diligently (cc'ing rwaldron in case he is motivated in this forEach case). So: always check Allen's latest draft. It trumps the wiki, unless there's a bug (and it may be hard to know without reading es-discuss or just asking here, cc'ing Allen). /be __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Wiki and drafts (was: Polyfill for Maps and Sets)
Cool, check this: https://mail.mozilla.org/pipermail/es-discuss/2013-January/028270.html :) That's not all of them, but I'll go through it all again for anything I missed (unless you want to list any here, which would be fantastic) Rick On Fri, Jan 18, 2013 at 1:08 PM, David Bruant bruan...@gmail.com wrote: Le 18/01/2013 18:58, Rick Waldron a écrit : It doesn't seem reasonable to maintain two versions of the proposals as they become specifications. My first thought is that the simplest possible strategy is to update harmony proposal pages (on the wiki) with a line at the top that indicates that the proposal is now in the spec draft. This is low effort-cost to convey that everyone should be looking at the latest and greatest of each proposal as they become part of the ES6 draft revisions and progress towards finalization therein. I fully agree. It'll bring more attention to what happens in the drafts and will make more people to review them. Also, if something in the harmony namespace is put on hold like harmony:classes it should probably be downgraded to the strawman namespace. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Wiki and drafts (was: Polyfill for Maps and Sets)
I think part of the confusion is that, from what I understand, harmony refers to things that are agreed upon by all TC39 members, or at least were at one time. But this does not imply it being in ES6. That is, much confusion I've seen on the internet stems from people assuming harmony means ES6, since for so long we were calling it ECMAScript Harmony. I'd suggest either downgrading non-ES6 proposals to strawman, or creating a new es6 namespace and moving the relevant pages there. The former is probably very appropriate for things that were once harmonious, but now contentious or obsoleted by other features. -- Of course, the actual solution for all this is for me to launch a bunch of pull requests against Dave's new wiki, giving it the same breadth and depth as the current one. Then we can point the internet to that as the authoritative source of information, with the current wiki used more as a scratchpad or historical archive. I'll try to re-shuffle my to-do list... From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Rick Waldron [waldron.r...@gmail.com] Sent: Friday, January 18, 2013 13:20 To: David Bruant Cc: Brendan Eich; es-discuss Steen Subject: Re: Wiki and drafts (was: Polyfill for Maps and Sets) Cool, check this: https://mail.mozilla.org/pipermail/es-discuss/2013-January/028270.html :) That's not all of them, but I'll go through it all again for anything I missed (unless you want to list any here, which would be fantastic) Rick On Fri, Jan 18, 2013 at 1:08 PM, David Bruant bruan...@gmail.commailto:bruan...@gmail.com wrote: Le 18/01/2013 18:58, Rick Waldron a écrit : It doesn't seem reasonable to maintain two versions of the proposals as they become specifications. My first thought is that the simplest possible strategy is to update harmony proposal pages (on the wiki) with a line at the top that indicates that the proposal is now in the spec draft. This is low effort-cost to convey that everyone should be looking at the latest and greatest of each proposal as they become part of the ES6 draft revisions and progress towards finalization therein. I fully agree. It'll bring more attention to what happens in the drafts and will make more people to review them. Also, if something in the harmony namespace is put on hold like harmony:classes it should probably be downgraded to the strawman namespace. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Wiki and drafts (was: Polyfill for Maps and Sets)
No. Harmony refers to the agreed post-ES5 trajectory of the language. It was part of the harmonious agreement to accept ES3.1 as ES5. ES6 and ES7 are both steps of ES-Harmony. On Fri, Jan 18, 2013 at 10:48 AM, Brandon Benvie bran...@brandonbenvie.com wrote: My understanding is that harmony refers perpetually to ES-next, whatever that thing is at the time. Since ES6 now has a name and a (draft) spec, it no longer is harmony (it's ES6). The wiki doesn't reflect this, but this is what (I think) I have observed from what TC39 members have said. On Fri, Jan 18, 2013 at 1:45 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I think part of the confusion is that, from what I understand, harmony refers to things that are agreed upon by all TC39 members, or at least were at one time. But this does not imply it being in ES6. That is, much confusion I've seen on the internet stems from people assuming harmony means ES6, since for so long we were calling it ECMAScript Harmony. I'd suggest either downgrading non-ES6 proposals to strawman, or creating a new es6 namespace and moving the relevant pages there. The former is probably very appropriate for things that were once harmonious, but now contentious or obsoleted by other features. -- Of course, the actual solution for all this is for me to launch a bunch of pull requests against Dave's new wiki, giving it the same breadth and depth as the current one. Then we can point the internet to that as the authoritative source of information, with the current wiki used more as a scratchpad or historical archive. I'll try to re-shuffle my to-do list... From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Rick Waldron [waldron.r...@gmail.com] Sent: Friday, January 18, 2013 13:20 To: David Bruant Cc: Brendan Eich; es-discuss Steen Subject: Re: Wiki and drafts (was: Polyfill for Maps and Sets) Cool, check this: https://mail.mozilla.org/pipermail/es-discuss/2013-January/028270.html :) That's not all of them, but I'll go through it all again for anything I missed (unless you want to list any here, which would be fantastic) Rick On Fri, Jan 18, 2013 at 1:08 PM, David Bruant bruan...@gmail.com wrote: Le 18/01/2013 18:58, Rick Waldron a écrit : It doesn't seem reasonable to maintain two versions of the proposals as they become specifications. My first thought is that the simplest possible strategy is to update harmony proposal pages (on the wiki) with a line at the top that indicates that the proposal is now in the spec draft. This is low effort-cost to convey that everyone should be looking at the latest and greatest of each proposal as they become part of the ES6 draft revisions and progress towards finalization therein. I fully agree. It'll bring more attention to what happens in the drafts and will make more people to review them. Also, if something in the harmony namespace is put on hold like harmony:classes it should probably be downgraded to the strawman namespace. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Wiki and drafts
On Fri, Jan 18, 2013 at 2:09 PM, Brendan Eich bren...@mozilla.com wrote: What was Harmonious prospectively can still be Harmonious in ES6 (as in ES5, remember, Harmony started in July 2008). The wiki harmony: namespace remains. I agree with the idea already in practice that Rick cited. Big note/link at top, leave the harmony: proposal as it was for historical purposes. We can certainly clean out the harmony: namespace of ES6 proposals, but more when ES6 is done -- IMHO. Thoughts? I agree with waiting until ES6 is done. When the spec is published, the harmony:proposals that are in that published document can be safely archived (or whatever the process is for the wiki) without creating chaos for Allen during the process. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Wiki and drafts (was: Polyfill for Maps and Sets)
On Fri, Jan 18, 2013 at 2:13 PM, Mark S. Miller erig...@google.com wrote: No. Harmony refers to the agreed post-ES5 trajectory of the language. It was part of the harmonious agreement to accept ES3.1 as ES5. ES6 and ES7 are both steps of ES-Harmony. I believe a good example is Object.observe, which is a harmonious proposal (accepted by all in the committee) that's on track for ES7, instead of ES6. Rick On Fri, Jan 18, 2013 at 10:48 AM, Brandon Benvie bran...@brandonbenvie.com wrote: My understanding is that harmony refers perpetually to ES-next, whatever that thing is at the time. Since ES6 now has a name and a (draft) spec, it no longer is harmony (it's ES6). The wiki doesn't reflect this, but this is what (I think) I have observed from what TC39 members have said. On Fri, Jan 18, 2013 at 1:45 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I think part of the confusion is that, from what I understand, harmony refers to things that are agreed upon by all TC39 members, or at least were at one time. But this does not imply it being in ES6. That is, much confusion I've seen on the internet stems from people assuming harmony means ES6, since for so long we were calling it ECMAScript Harmony. I'd suggest either downgrading non-ES6 proposals to strawman, or creating a new es6 namespace and moving the relevant pages there. The former is probably very appropriate for things that were once harmonious, but now contentious or obsoleted by other features. -- Of course, the actual solution for all this is for me to launch a bunch of pull requests against Dave's new wiki, giving it the same breadth and depth as the current one. Then we can point the internet to that as the authoritative source of information, with the current wiki used more as a scratchpad or historical archive. I'll try to re-shuffle my to-do list... From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Rick Waldron [waldron.r...@gmail.com] Sent: Friday, January 18, 2013 13:20 To: David Bruant Cc: Brendan Eich; es-discuss Steen Subject: Re: Wiki and drafts (was: Polyfill for Maps and Sets) Cool, check this: https://mail.mozilla.org/pipermail/es-discuss/2013-January/028270.html:) That's not all of them, but I'll go through it all again for anything I missed (unless you want to list any here, which would be fantastic) Rick On Fri, Jan 18, 2013 at 1:08 PM, David Bruant bruan...@gmail.com wrote: Le 18/01/2013 18:58, Rick Waldron a écrit : It doesn't seem reasonable to maintain two versions of the proposals as they become specifications. My first thought is that the simplest possible strategy is to update harmony proposal pages (on the wiki) with a line at the top that indicates that the proposal is now in the spec draft. This is low effort-cost to convey that everyone should be looking at the latest and greatest of each proposal as they become part of the ES6 draft revisions and progress towards finalization therein. I fully agree. It'll bring more attention to what happens in the drafts and will make more people to review them. Also, if something in the harmony namespace is put on hold like harmony:classes it should probably be downgraded to the strawman namespace. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Can JS Algorithm object finally solve html5 codecs gridlock and move us forward?
Hi guys I am playing with web audio api and mozilla audio api but I got frustrated about so much html5 potential wasted due to infinite codecs deadlock support in browsers holding progress back for so long. This even resulted to people writing codecs purely in JS. Unfortunately performance is obviously slow and limiting to browsers allowing raw data from js And slow mainly because of huffman and imdct. But looking at block diagrams of pretty much any widespread codec like theora ogg mpg aac mp4 it striked me. Since they pretty much share the same building blocs. and which themself are not that much patent encumbered. So why not just introduce new Algorithm object in JS and just register huffman idct imdct filterbank in it. for browsers its easy task they just make visible already heavily hw optimized pretty much 4 or so functions that are already in them And then suddenly you can have theora ogg flac acc or pretty much any media decoded in js in all browsers but with speeds approaching those on native hw. just look at incredible work of talented guys at official.fm and their js codecs even for flac Another advantage of hw accelerated thing like huffman in js is that it sits in pretty much every block of data around us. compressed files like gz bz2 cab jar zip rar 7z images pdf jpg png tiff and pretty much any music or movie format. This can create interesting new usage possibilities for JS and heavily complement new things like web-sockets faster transport or webgl custom textures / compressed meshes or fileapi custom format decoders / renderers in js So even thou its just 4 functions (that are already implemented just need to be registered in JS) and the impact on html5 and web future landscape can be interesting. All that is needed is agreement on content of such Algorithm object it can surely promote current or even new open unencumbered codecs in all browsers. I bet small but powerful teams like opera guys will be more than happy and way better than risking another gif like threat from current patent submarine formats. So what you guys think about such new Algorithm object and registration of those existing 4 funcs in new JS Ecmascript6 ? Ladislav Nevery Sent from my iPad ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxy target as __proto__? (Re: Proxy's optional target)
Hi Tom,
I'm not sure I fully understand your proposal, but could you not achieve it
by simply doing:
var target = ...; // might be frozen
var p = Proxy( Object.create(target), handler);
Ah, too obvious for me, thanks!
Also, proxy wrappers often modify functions, which tend to be on
a non-frozen prototype. So perhaps it isn't as big an issue as I thought.
Claus
PS. I probably shouldn't mention that Proxies' invariant checks
only against own properties behave differently from how non
Proxy objects behave, if a target prototype property happens
to be frozen (override prohibition non-mistake)?
var x = Object.freeze({foo: 88});
var y = Object.create(x);
y.foo = 99; // fail
console.log( y.foo ); // 88
var yp = Proxy(y,{get:function(t,n,r){ return n===foo ? 99 : t[n] } });
console.log( yp.foo ); // 99
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Can JS Algorithm object finally solve html5 codecs gridlock and move us forward?
Hi Ladislav, Le 18/01/2013 22:51, neuralll a écrit : Hi guys I am playing with web audio api and mozilla audio api but I got frustrated about so much html5 potential wasted due to infinite codecs deadlock support in browsers holding progress back for so long. This even resulted to people writing codecs purely in JS. Unfortunately performance is obviously slow and limiting to browsers allowing raw data from js How slow? I'm not familiar with the performance story here and I wonder how slow it is, for which sound quality on a modern browser with normal hardware, etc. Do transferables WebWorkers make the story better? (I don't know how much these algorithms work in parallel) What is the slowness due to in current browsers? Is there a known bottleneck in current browsers implementations? And slow mainly because of huffman and imdct. But looking at block diagrams of pretty much any widespread codec like theora ogg mpg aac mp4 it striked me. Since they pretty much share the same building blocs. and which themself are not that much patent encumbered. So why not just introduce new Algorithm object in JS and just register huffman idct imdct filterbank in it. for browsers its easy task they just make visible already heavily hw optimized pretty much 4 or so functions that are already in them And then suddenly you can have theora ogg flac acc or pretty much any media decoded in js in all browsers but with speeds approaching those on native hw. What is the expected performance gains? And I expect numbers as an answer, hopefully backed by some benchmarks. just look at incredible work of talented guys at official.fm and their js codecs even for flac So... that's a JS codec? I think if they made it work, it's basically an argument in favor of *not* adding these algorithms to the language. Reading a bit more about it [1]. Quotes: With [these JS libraries], it is possible to play MP3, Apple Lossless, FLAC, and AAC even in browsers without native support. With JSMad we showed that decoding audio in JavaScript is possible, courtesy of these APIs and the hard work of browser creators and spec authors. I'm kind of puzzled. They made it work to a level they find acceptable with current browser capabilities. What else do you need? David [1] http://labs.official.fm/codecs/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
