Re: Proxy Reflect.has() call causes infinite recursion? (#!/JoePea)

[Alex Vincent]

I'm afraid your testcase is still far too complicated to really figure out
at first glance.  It looks like you're trying to implement a mixin pattern.

In my experience, it's better to implement the getPrototypeOf,
getOwnPropertyDescriptor, and defineProperty traps, and maybe make your
get, set, and has traps depend on them.

Yes, that means you have to read the ECMAScript specification, section 9.5
carefully.  Yes, it's a major pain point.  I can only point you to my own
efforts in es-membrane to implement the specified traps.

https://github.com/ajvincent/es-membrane/blob/master/source/ObjectGraphHandler.js
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Polyfilling Object.observe

[Alex Vincent]

> `Proxy` is powerful, but it's not as good as `Object.observe` would've
> been for some very simple tasks.
>
> Every time I wish I could use `Proxy` in a simple way, there's always some
> issue with it. For example: https://jsfiddle.net/trusktr/hwfontLc/17
>

Because you are doing it wrong.

Proxies can *only* observe on the object that they're created for.  By
setting Foo.prototype to a proxy, you can only observe operations on
Foo.prototype, not instances of Foo.

What you really want is to have new Foo() return a Proxy... which is
counter-intuitive, admittedly, because we're all taught that a constructor
should never explicitly return a value.

This problem has been solved, a few times, with the introduction of
membranes in JavaScript.  In that environment, you would start with Foo and
wrap it in a membrane proxy. Then, in invoking new Foo(), the "construct"
trap of that proxy would return another roxy automatically, probably using
the same proxy handler but a different proxy target.

If it's any consolation, proxies are in general very hard to work with.
You're only scratching the surface here.  I recently gave a talk at TC39
(the standards body for ECMAScript) on membranes.  One key takeaway is that
the overhead in dealing with membrane-oriented proxies really is better off
left to a library built for that purpose.

Tom van Cutsem is working on an article summarizing the current state of
membranes.  I'm not sure if he has approved its general release yet, so
stay tuned...

Alex Vincent
Edmonds, WA (on vacation)

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Small Proposal "!in"

[Alex Vincent]

In Linux programming, #!/bin/bash is very commonly the first line of a
shell script. In Python, we have #!/bin/python, or #!/bin/perl.  The #!
characters are pronounced "she-bang", because # is pronounced "hash" and !
is pronounced "bang".
https://en.wikipedia.org/wiki/Shebang_(Unix)

On Wed, Jul 11, 2018 at 8:47 AM, Ben Wiley 
wrote:

> I find the juxtaposition of a symbol operator against an English operator
> a bit odd, but I think most English speakers pronounce "!" as "not" so you
> might not have so much to worry about..
>
> Le mer. 11 juill. 2018 11 h 24, Alex Vincent  a
> écrit :
>
>> Also, there's the little matter of pronunciation.  I admit to a bit of
>> snarkiness when I first saw this proposal, but I didn't expect it to have
>> any traction.  So I'll just say it:  do we really want JavaScript to be a
>> "bangin' " language?
>>
>> Alex
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Small Proposal "!in"

[Alex Vincent]

>
> -- Forwarded message --
> From: Andrea Giammarchi 
> To: Jordan Harband 
> Cc: "es-discuss@mozilla.org" 
> Bcc:
> Date: Wed, 11 Jul 2018 16:23:03 +0200
> Subject: Re: Small Proposal "!in"
> and, as previously mentioned, `!obj.x` might have side effects through the
> accessor, as example in every lazily defined property that would be early
> defined (or anything else behind a getter that could do more than just
> telling the property is there and it's not truthy).
>

Peanut gallery observation: I personally think !in is a Really Bad Idea, or
at least I'm not convinced that it's particularly useful.  If it is useful,
then let one of the transpiling languages like CoffeeScript or TypeScript
demonstrate it first.

Also, there's the little matter of pronunciation.  I admit to a bit of
snarkiness when I first saw this proposal, but I didn't expect it to have
any traction.  So I'll just say it:  do we really want JavaScript to be a
"bangin' " language?

Alex

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Overload str.replace to take a Map?

[Alex Vincent]

Reading [1] in the digests, I think there might actually be an API
improvement that is doable.

Suppose the String.prototype.replace API allowed passing in a single
argument, a Map instance where the keys were strings or regular expressions
and the values were replacement strings or functions.

Advantages:
* Shorthand - instead of writing str.replace(a, b).replace(c, d).replace(e,
f)... you get str.replace(regExpMap)
* Reusable - the same regular expression/string map could be used for
several strings (assuming of course the user didn't just abstract the call
into a separate function)
* Modifiable on demand - developers could easily add new regular expression
matches to the map object, or remove them
* It wouldn't necessarily break existing API, since
String.prototype.replace currently accepts only RegExp or strings.

Disadvantages / reasons not to do it:
* Detecting collisions between matching regular expressions or strings.
If two regular expressions match the same string, or a regular expression
and a search string match, the expected results may vary because a Map's
elements might not be consistently ordered.  I don't know if the ECMAScript
spec mandates preserving a particular order to a Map's elements.
  - if we preserve the same chaining capability
(str.replace(map1).replace(map2)...), this might not be a big problem.

The question is, how often do people chain replace calls together?

* It's not particularly hard to chain several replace calls together.  It's
just verbose, which might not be a high enough burden to overcome for
adding API.

That's my two cents for the day.  Thoughts?

[1] https://esdiscuss.org/topic/adding-map-directly-to-string-prototype

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

This mailing list needs a FAQ page.

[Alex Vincent]

I hate to say it, but I keep seeing the same dozen ideas surfaced over and
over again here.  We really should capture them in a HTML page with link
targets.  I'd like to see a format of:

Q: I have this idea or I want this in the language...
A: Hyperlink to a TC39 spec, a library or an explanation why it's a bad
idea.

It'd be nice to add it to the message headers, right above those
unsubscribe links that nobody bothers to search for.

Any volunteers?

Alex
-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggested Enhancement to ecmascript

[Alex Vincent]

> -- Forwarded message --
> From: Sebastian Malton 
> To: Pranay Prakash , "Michał Wadas" <
> michalwa...@gmail.com>
> Cc: Matthew Tedder , es-discuss <
> es-discuss@mozilla.org>
> Bcc:
> Date: Fri, 11 May 2018 18:25:08 -0400
> Subject: Re: Suggested Enhancement to ecmascript
> What would be nice is if we could have a good way of watching a variable.
> Maybe a built in way to create a custom event emitter.
>

Watching a variable directly might not be available.  That said, if you're
willing to wrap the variable in an object, it's very doable via property
descriptors.  They allow you to implement getters and setters which refer
to another property, either publicly exposed or in a closure.

Keep in mind private variables don't really exist - yet - in ECMAScript.
They can be achieved right now through a JavaScript Proxy, but that's
pretty heavy-weight, and tricky to get right.  I've been working on a
proxy-based library to do exactly that, named es-membrane... and I'm still
looking for help for the times when I'm just too busy.

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Allow Promise callbacks to be removed

[Alex Vincent]

> My proposal is that we add a way of removing a particular callback, or all
> callbacks, from a Promise. This is different to cancelling a Promise and
> would instead happen if you want the operation to continue but are no
> longer interested in running a function when the Promise is resolved or
> rejected.
>

Devil's advocate from the peanut gallery:  what's so hard about adding:

```javascript
if (!isStillValid) return;
```
-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Strawman: Module Keys

[Alex Vincent]

On Wed, Feb 28, 2018 at 4:00 AM,  wrote:

> From: Mike Samuel I'm looking for other criticism
> of https://github.com/mikesamuel/tc39-module-keys and for interested
> parties who might have time to refine it.


I'm just taking a bit of time to read over it.  Keep in mind, I'm no
security expert.

In the spec, you write,

> We use the name frenemies below. This is a terrible name.


I suggest "counterparties".
https://www.investopedia.com/terms/c/counterparty.asp

What's a Box?  (I'm serious.  You really don't define what it is in this
context.)  You also talk about boxed values and unboxed values, but I may
have missed the paragraphs explaining the difference.

In your example code sections, you imply these properties are directly
named as properties of alice and bob, respectively... do we want all of
those as such, or maybe under a namespace
(alice[someNameOrSymbol].publicKey)?  Particularly with such generic names
as box and unbox...
I'd feel more comfortable if they were under a predefined
Symbol.MODULE_KEYS namespace.

That's my two cents - and they're worth exactly that much after inflation.
:-)

Alex

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Identifying pure (or "pure within a scope") JavaScript functions?

[Alex Vincent]

TLDR:  -1 is much more useful in mathematics than in expressing an opinion.

Mr. Zhu,

In this case I am the implementer, and I generally know what I'm doing
after well over fifteen years of working with the language, including the
membrane library we're talking about, and including writing an 1100+ page
book on the language.  (The latter taught me a lot, by the way.  You should
try it sometime.  It's a very humbling experience, both at the time for
what you thought you knew that's actually quite wrong, and much later in
life, when you realize what you still got wrong.  I only hope Martin Honnen
is still around for me to reiterate my thanks to...)

I shouldn't be worried about the garbage collector, and I'm not.

But I do know how my membrane can (a) create and (b) hold onto references.
This wasn't about the garbage collector at all.  This was about avoiding
creating the proxy and thus, the reference, in the first place.  I am
dealing with the concept of "when is wrapping something in the membrane
counter-productive in some way".

I said "essentially a memory leak", not meaning to be taken entirely
literally.  It is a memory leak in the sense that unless somebody visits
that proxy again -- which no one will ever know if it's necessary or not --
the reference to the proxy will remain alive.  For that proxy to exist
because of a simple filter function is possibly less than ideal, to put it
politely.  Especially when said filter function can be called many times
for many different objects.

So yes, maybe it's premature optimization, and I'm always willing to admit
I'm wrong... when it's clear that I am.  In my case, I'm not looking at
micromanagement of the gc, but to avoid certain work in the first place.

Now, parsing a function's source code to find out if that function will,
say, set a global variable that it shouldn't, is probably pretty expensive
as well... *except that the JavaScript engine has already done that parsing
and might have retained some useful metadata that the specification doesn't
expose.*  Which is why I'm not particularly interested in adding esprima
and a bunch of code I don't understand for a small bit of metadata.  It's
why I came to this mailing list today, to ask the experts, "Hey, is this a
good idea to look into?  I actually have a use-case, and it's not something
that can be easily done in raw JS."  That's my understanding of the general
requirements for adding new API.

I already explored at least two other ideas that turned into dead ends, and
it's quite possible (probable, given the feedback) that this one will be a
dead end too.  I'm fine with that.

So sure, asking end users to micromanage or optimize their code is
irresponsible.  But I'm writing a library for developers to use, and if I
can provide advice on the best way to use that library, I think it's worth
the time to think about how that library works, and how to be nice to the
machines that it will run on.  So I'd better think a lot about optimizing *my
*code, and about helping *my* users get the best reactions from it.

On Thu, Dec 7, 2017 at 11:26 AM, kai zhu  wrote:

> This led down a long, rambling path [1] where I then realized:  if the
> callback function is a pure function, then for the purposes of that
> callback, the arguments probably do not need to be wrapped in proxies at
> all.  The big catch is that the callback can't store any of the arguments
> in variables external to the callback (a classic side effect).  If the
> function really is pure, though, I can avoid the memory leak.
>
>
> -1
> users generally should not be encouraged to micro-manage/optimize the gc
> in javascript (javascript is not c). that is the responsibility of
> engine-implementers. making users think they can outsmart the gc (which
> they don't) will only encourage them to waste time writing
> “high-performance” code that is bike-shedding at best and tech-debt at
> worst (and my suspicion is membrane/proxy will suffer either of those fates
> with this feature).
>
> On Dec 8, 2017, at 2:22 AM, Mike Samuel  wrote:
>
>
>
> On Thu, Dec 7, 2017 at 1:11 PM, Alex Vincent  wrote:
> > OK, OK, clearly, pure functions are a fantasy in JavaScript.  Once
> again, a
> > great idea and a lengthy essay of a post falls to a real-world situation.
> > Nuts.
> >
> > What if there's a middle ground?  In the case I was originally talking
> > about, the developer calling on my membrane controls how the callback
> > function executes.  I just want to ensure that, when the callback is
> passed
> > controlled and trusted arguments (including possibly "this"), the
> function
> > doesn't refer to anything outside those arguments and lo

Re: Identifying pure (or "pure within a scope") JavaScript functions?

[Alex Vincent]

OK, OK, clearly, pure functions are a fantasy in JavaScript.  Once again, a
great idea and a lengthy essay of a post falls to a real-world situation.
Nuts.

What if there's a middle ground?  In the case I was originally talking
about, the developer calling on my membrane controls how the callback
function executes.  I just want to ensure that, when the callback is
passed *controlled
and trusted* arguments (including possibly "this"), the function doesn't
refer to anything outside those arguments and local variables derived from
them.  Is that reasonable to ask for?

Call this check "is relatively pure", or "is locally pure", if you desire.
If the inputs themselves manipulate globals, "absolutely pure" can never be
guaranteed, as was just demonstrated...

On Thu, Dec 7, 2017 at 9:35 AM, Michael Haufe 
wrote:

> Relevant discussions:
>
>  2Y9ORBwCIQAJ>
>
> and:
>
>  November/thread.html#26657>
>
>
> On Thu, Dec 7, 2017 at 11:15 AM, Michał Wadas 
> wrote:
>
>> Only extremely small subset of functions can be proven to be pure. And I
>> suppose that these functions are already optimized by engines.
>>
>> eg.
>> notPure = (a,b) => a + b; // implicit conversion with side effects can
>> happen
>> notPure = (a) => a && a.b; // getter can be called
>> notPure = (foo, bar) => Reflect.has(foo, bar); // proxy trap can be
>> called. Someone could overwrite Reflect.has
>>
>> etc.
>>
>> It would be better idea to have builtin decorator *@pure* that allow
>> engine to remove or reorganize function calls (and valid implementation can
>> treat it as no-op).
>>
>


-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Identifying pure (or "pure within a scope") JavaScript functions?

[Alex Vincent]

TLDR:  I'm asking for the group to consider adding a Function.isPure(func)
or isPureWithinScope() to the ECMAScript specification, to help code detect
pure functions.

This morning, I had a thought experiment about membranes, and in
particular, callback functions passed into them.  If the callback function
is called repeatedly for objects that will not be needed again, that means
one extra proxy for each object, which the membrane must remember.  That's
effectively a memory leak.

This led down a long, rambling path [1] where I then realized:  if the
callback function is a pure function, then for the purposes of that
callback, the arguments probably do not need to be wrapped in proxies at
all.  The big catch is that the callback can't store any of the arguments
in variables external to the callback (a classic side effect).  If the
function really is pure, though, I can avoid the memory leak.

But how can I tell from JavaScript, easily, whether a function is pure or
not?

For reference, a quick search on es-discuss found [2], which is probably
worth re-reading.

Determining whether a function is pure or not (or "only uses these
objects") is probably best left up to JavaScript parsers.  Although it
could be done using esprima, I suppose, that's a lot to ask of a membrane.

So the first question I have is, would this group actively consider adding
a built-in Function.isPure(func) method to the ECMAScript language?  (Or
Function.prototype.isPure(), but I prefer the former.)

Further, in the case where a function isn't pure but its side effects are
confined to local variables that won't live longer than the callback, that
might also be safe for not wrapping in the membrane.  I'm thinking of a DOM
NodeFilter object where the acceptNode method modifies the filter, but the
filter is defined via a let statement in a small scope statement-block.
Since I don't know what to call this kind of function, I'll temporarily
call it "pure within a scope" until someone corrects me.  What I mean by
"pure within a scope" is that the function's only side effects involve
objects within that set.

The second question then is, would this group actively consider a built-in
function which takes a target function to test as its first argument and an
array of objects that are considered safe for that target function to work
with, and returns true if the target function has no side effects besides
directly impacting the objects in the array?  (No, I don't know what to
call the built-in function.  Maybe Function.isPureWithinScope(func,
safeObjectsArray).)

Alex Vincent
Hayward, CA, U.S.A.

[1] https://github.com/ajvincent/es7-membrane/issues/141
[2] https://esdiscuss.org/topic/pure-functions-in-ecmascript

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Multi-index assignment.

[Alex Vincent]

>
> -- Forwarded message --
> From: Jordan Harband 
> To: "/#!/JoePea" 
> Cc: es-discuss 
> Bcc:
> Date: Mon, 4 Dec 2017 11:28:22 -0800
> Subject: Re: Multi-index assignment.
> Can you elaborate on these situations?
>
> In general, I find that using specific array indexes is most often a code
> smell.
>

Agreed, and depending on the programming language, commas in square
brackets has a different meaning.  Way back when I was a child working with
BASIC (I think), foo[1, 2] meant a two-dimensional array, what we now call
foo[1][2].

It sounds like you are trying to abuse object destructuring here... in a
way that is probably dangerous.
-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Debuggers and async/await should work together better: I have testcases.

[Alex Vincent]

As requested, I've filed
https://github.com/devtools-html/debugger.html/issues/4853 .  Thanks for
the help in advance!

Alex

On Fri, Dec 1, 2017 at 8:58 AM, Jason Orendorff 
wrote:

> Alex,
>
> I asked around, and our debugger folks say that stepping over await should
> work in current shipping Firefox. Haven't checked out your test case yet,
> but someone here will.
>
> In any case, please do report a bug! Instead of Bugzilla, report it here:
>   https://github.com/devtools-html/debugger.html/issues
>
> If you don't mind Slack, you can hop on this one (and ping @yulia or
> @jorendorff) to talk more about async debugging:
>   https://devtools-html.slack.com/
>   https://devtools-html-slack.herokuapp.com/  <-- to sign up
>
> -j
>
>
>
> On Fri, Dec 1, 2017 at 3:27 AM, Alex Vincent  wrote:
>
>> A few minutes ago, I released version 0.8.2 of the es7-membrane project.
>> [1]  I've been using Mozilla Firefox primarily to debug it as I go, and I
>> find the built-in JavaScript debugger has a few quirks when asynchronous
>> functions come into the mix...
>>
>> Most notably, when I step over an "await" statement, the debugger treats
>> it as if I'm exiting the function altogether.
>>
>> Also, exceptions thrown within the async functions after an await tend
>> not to show up when I'm stepping through the code.
>>
>> I know I should be filing this in Bugzilla, and I will this weekend...
>> I'm posting this here for all JS engine & debugging tools teams, as a
>> heads-up:  when it comes to async functions, the step-through-code user
>> experience is subpar.
>>
>> As for tests people can step through to see what I'm talking about:  see
>> [1] for the source under docs/gui/tests.  To run the tests, type |npm run
>> gui-tests|.  I use Karma to implement the tests. The karma.conf.js file in
>> the root directory has a "singleRun" setting that developers can change to
>> false for debugging purposes (attaching breakpoints to a test, for example).
>>
>> If it's on a weekend, I can be available to demonstrate what I'm
>> referring to, or to show people how to reproduce these behaviors.
>>
>> Thanks!
>>
>>
>>
>> Alex Vincent
>> Hayward, CA, U.S.A.
>>
>> [1] https://github.com/ajvincent/es7-membrane
>>
>>
>> --
>> "The first step in confirming there is a bug in someone else's work is
>> confirming there are no bugs in your own."
>> -- Alexander J. Vincent, June 30, 2001
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>


-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Debuggers and async/await should work together better: I have testcases.

[Alex Vincent]

A few minutes ago, I released version 0.8.2 of the es7-membrane project.
[1]  I've been using Mozilla Firefox primarily to debug it as I go, and I
find the built-in JavaScript debugger has a few quirks when asynchronous
functions come into the mix...

Most notably, when I step over an "await" statement, the debugger treats it
as if I'm exiting the function altogether.

Also, exceptions thrown within the async functions after an await tend not
to show up when I'm stepping through the code.

I know I should be filing this in Bugzilla, and I will this weekend... I'm
posting this here for all JS engine & debugging tools teams, as a
heads-up:  when it comes to async functions, the step-through-code user
experience is subpar.

As for tests people can step through to see what I'm talking about:  see
[1] for the source under docs/gui/tests.  To run the tests, type |npm run
gui-tests|.  I use Karma to implement the tests. The karma.conf.js file in
the root directory has a "singleRun" setting that developers can change to
false for debugging purposes (attaching breakpoints to a test, for example).

If it's on a weekend, I can be available to demonstrate what I'm referring
to, or to show people how to reproduce these behaviors.

Thanks!



Alex Vincent
Hayward, CA, U.S.A.

[1] https://github.com/ajvincent/es7-membrane


-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Encoding symbol keys in JSON?

[Alex Vincent]

In modern ECMAScript, objects can have symbols for property names instead
of strings.  This leads me to a problem in my es7-membrane project:  how do
I translate those symbol keys into JSON for a reusable file?  (I partially
answer my own question below.)

Consider the following code:

  const X = {};
  const two = Symbol("two");
  Reflect.defineProperty(X, "one", {value: 1, writable: true, enumerable:
true, configurable: true});
  Reflect.defineProperty(X, two,   {value: 2, writable: true, enumerable:
true, configurable: true});
  return JSON.stringify(Reflect.ownKeys(X));

In both Mozilla Firefox and Google Chrome, this returns ["one", null].  I
suppose this is part of the ECMAScript's latest standard. I do see
JSON.stringify has a "replacer" callback argument, and JSON.parse has a
"reviver" argument.  I presume that these are here to solve
encoding/decoding problems with JSON.  This may be the route I take...

At first, serializing shouldn't be a problem:  if I hit a symbol as a key,
I could use the replacer functionality to deliver a standard
JSON-serializable object.

But what if the ordering of keys is not guaranteed?  I'm referring
specifically to the case of a developer modifying X's properties in the
above snippet - say, by defining Symbol("three") as a key before the two
key.  Or worse, by defining a different Symbol("two") before the existing
two key?  I am not referring to the case of the developer modifying the
results from Result.ownKeys().

Now, all of a sudden, this little stringify problem has possibly morphed
into a diff/merge problem:  between yesterday's serialized JSON for ownKeys
and today's, someone has cleverly inserted a symbol where there was another
in the list of keys.  My code is supposed to infer today from yesterday's
generated JSON which property key belongs to which property value.  With
symbols - especially identically-keyed symbols - I could lose that
consistency if I'm not careful.

(Side note:  for es7-membrane, I faced a similar but easily solvable
problem, where Reflect.ownKeys(function() {}) returned different results in
different browsers - especially when the function passed into ownKeys had
additional properties.  In that case all the properties were strings, so I
just extracted the common set of string-named properties and put them at
the front of the keys list for consistency.)

I'm looking for advice - including the very real possibility that I'm
overthinking this or worrying too much about an edge case.

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Proxy.[[GetOwnProperty]] caching non-configurable, non-writable data descriptors?

[Alex Vincent]

> -- Forwarded message --
> From: Oriol _ 
> Instead of storing the properties in a map, I think you could first call
> [[GetOwnProperty]] on the target, and if it's not configurable nor
> writable, return the same descriptor without calling the proxy trap.
>

I believe that's what my original suggestion was.

However, I disagree with this kind of things. Proxy traps are not only
> useful because of the value they return, they can also have desirable
> side-effects.
>
> --Oriol
>

You make an annoyingly good point here... :-) I made a similar point a few
months ago to someone who wanted to create a "hybrid" object which hid the
proxy as the prototype of a regular object, for speed.  *shudder*

That said, I still believe the algorithm I pointed out goes through a lot
of steps that *can* be unnecessary in the scenario I laid out... except
that the creator of the proxy has no way of telling the implementing engine
that.  There's no "proxy configuration options" that I can modify to pass
these optimizing hints to the engine.  Maybe *that's* something we might
need.

I know, this is quite a stretch, suggesting more API for proxies.  (I still
want Reflect.parse to happen, after all, and unlike kai zhu, I think
operator overloading is a good thing...)  I "blame" (actually, credit) Tom
van Cutsem for that, as he made a suggestion about optional properties
being an object in my own Membrane API recently.  It was a good idea there,
and for other algorithmic shortcuts in proxy traps, it might be a good idea
here.

I also take Caridy's point about Google Chrome 62's optimizations that are
coming.  I didn't know that was actually happening until Caridy posted
about it here.

Thanks for your response, though:  it's nice to know someone cares about
this.

Alex

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Suggestion: Proxy.[[GetOwnProperty]] caching non-configurable, non-writable data descriptors?

[Alex Vincent]

Proxies are a little slow right now, and maybe the rules of ECMAScript can
safely allow for caching a non-configurable, non-writable data descriptor.

Specifically, in ValidateAndApplyPropertyDescriptor from ES8 (section
9.1.6.3, step 7a-iii), we've already shown current and desc both have the
following traits:

   1. isDataDescriptor(current) and isDataDescriptor(desc) return true
   2. [[Configurable]] is false
   3. [[Writable]] is false
   4. SameValue(Desc.[[Value]], current.[[Value]]) is true
   5. The [[GetOwnProperty]] or [[DefineOwnProperty]] internal method is
   executing, indirectly calling ValidateAndApplyPropertyDescriptor for this
   case.
   6. The [[Get]] or [[Set]] internal methods is probably executing,
   calling [[GetOwnProperty]] or [[DefineOwnProperty]] for this case.

That is a very specific set of traits.  As I understand it, it means the
proxy target's property named P in Proxy.[[GetOwnProperty]] is permanently
locked and can never change - and so neither can the proxy ever report a
different value.  Therefore, calling on the proxy handler for that property
a second time is, at least in my view, either redundant or unnecessarily
expensive.

I would suggest that implementers in section 9.5 (Proxy internals)
optionally have a private Map where values that are non-configurable and
non-writable are stored.  Then [[GetOwnProperty]] could insert a couple of
new steps into its algorithm.  Between steps 4 and 5 of the current
algorithm, I would add:  "If the optional [[Map]] object exists and
[[Map]].has(P) returns true, return [[Map]].get(P)."  In step 17 of the
current algorithm, I would add a substep:  "If isDataDescriptor(resultDesc)
and resultDesc.[[Writable]] is false and the optional [[Map]] object
exists, call [[Map]].set(P, resultDesc).  (If the [[Map]] internal slot
exists but does not contain a Map, the [[Map]] may be filled with a Map at
this time.)"

I would also suggest similar changes for [[DefineOwnProperty]]. (Section
9.5.6)

Alternatively, if storing a specific descriptor in the Map is unpalatable,
the specification could request storing resultDesc.[[Value]] in step 17,
and create a new non-configurable, non-writable descriptor before the
current step 5.

Also, if a Map is too expensive, the spec could allow for an equivalent
native map or whatever other appropriate data structure
fills the need.

Counter-point (1):  if the intent of the proxy is to treat all property
look-ups equally, then caching the non-writable, non-configurable
descriptors goes against that intent - because now the trap is invoked only
once for properties returning this type of descriptor.  But there's a lot
of steps, including invoking a custom proxy handler trap with an unknown
number of steps, and a lot of complexity in that trap to ensure what it
returns will pass all the assertions in the spec.

Counter-point (2):  I don't know how common it is to have a property
descriptor that meets all six criteria at the beginning of this post, in
particular that both [[Configurable]] and [[Writable]] are false.  So this
does add another pointer, at least to null initially, for the [[Map]]
slot.  This is why I am proposing the [[Map]] slot as optional for
implementers.  Let the engines decide whether it's warranted or not as an
optimization.

Thoughts?


Alex Vincent

Hayward, CA, USA
-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proxy performance: JIT-compilation?

[Alex Vincent]

So, how many boxes of chocolates do I need to send to the two big vendors
in Mountain View?  :-)

It's been fifteen years since I seriously tried to profile C++ code, and I
didn't really know what I was doing back then:  unfamiliar tools, and less
competence in C++ than I would've liked.  What little knowledge of
profiling I had back then has long since faded.

Even if I could generate a pretty picture of how long we spent in each code
path, I wouldn't know how to interpret it.

I recently submitted a patch for improving error reporting in SpiderMonkey
[1], so I can occasionally dip my toes in the JSAPI code...

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1383630

On Fri, Aug 4, 2017 at 2:52 PM, Allen Wirfs-Brock 
wrote:

> I don’t think the barriers to such optimization are technical.  It’s more
> a matter of convincing that engine implementors that doing the work
> (probably significant)  to optimizing Proxies in this manner is a sound
> investment and hight priority
>

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proxy performance: JIT-compilation?

[Alex Vincent]

>
> In particular, for many permanently absent traps, the proxy can just pass
> these through directly to the target without much analysis.
>

Your suggested changes to the ECMAScript specifications seem to focus on
permanently absent traps... which doesn't do much good for present traps.
For instance, new Proxy({}, Reflect), which I mentioned in my initial
e-mail and, by the way, implements all the traps.  :-)

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proxy performance: JIT-compilation?

[Alex Vincent]

Recently, a fellow engineer observed that ECMAScript proxies are "around
700x slower" in retrieving a property than a simple getter function with a
closure.  He thought this meant "the JIT compiler can't optimize the code".

I'm not so sure, so I thought I'd ask the experts here.

Proxies are one of the frontiers of JavaScript, largely unexplored.  The
ECMAScript specification makes no mention whatsoever of just-in-time
compilation (rightly so, I would think).  But this means that proxy code
execution might be one of those areas where we do not currently enjoy the
benefits of JIT... and we could.

So, I have a direct question for JavaScript engine developers:  other than
having to look up and execute a proxy handler's traps, are there specific
reasons why proxy performance might be significantly slower than a simple
function execution?

I can imagine a three-fold performance test:  (1) direct inspection of an
object, (2) inspection of Proxy({}, Reflect), and (3) inspection of
Proxy({}, handler) where

allTraps.forEach(function(t) {
  handler[t] = function() {
return Reflect[t].apply(Reflect, arguments);
  }
});

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

[Alex Vincent]

Thanks, Jason.  I tried that approach last night (calling setPrototypeOf
within the getPrototypeOf trap), and it caused a nasty regression in one of
my other prototype-checking tests.  I assumed at the time that I had done
something wrong, but your quick summary shows that instead I was doing
something right, and that my prototype chain handling was incorrectly
implemented...

On Tue, May 23, 2017 at 9:26 AM, Jason Orendorff 
wrote:

> I think the most straightforward thing is something like this:
>
> https://gist.github.com/jorendorff/85d74ef7dce0118664535f84d57d6788
>
> To restate the obvious, this is a minimal fix for your minimized test
> case, not production code you can take and use. You'd need to implement all
> the rest of the handler methods.
>
>
> On Tue, May 23, 2017 at 11:01 AM, Alex Vincent 
> wrote:
>
>> Yes, I've been using the shadow technique in my es7-membrane project for
>> quite some time.  I was trying to minimize a fairly complex test case here.
>>
>> Obviously, I can reintroduce shadow targets into the minimal testcase,
>> but then I need to figure out how to make the prototype object I'm trying
>> to get consistent again... still working through the details of that in my
>> head.
>>
>> On Tue, May 23, 2017 at 8:50 AM, Mark S. Miller 
>> wrote:
>>
>>> Take a look at Tom's explanation of the "shadow target" technique at
>>> https://research.google.com/pubs/pub40736.html
>>> section 4.3
>>>
>>> --
>>> Cheers,
>>> --MarkM
>>>
>>
>>
>


-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

[Alex Vincent]

Yes, I've been using the shadow technique in my es7-membrane project for
quite some time.  I was trying to minimize a fairly complex test case here.

Obviously, I can reintroduce shadow targets into the minimal testcase, but
then I need to figure out how to make the prototype object I'm trying to
get consistent again... still working through the details of that in my
head.

On Tue, May 23, 2017 at 8:50 AM, Mark S. Miller  wrote:

> Take a look at Tom's explanation of the "shadow target" technique at
> https://research.google.com/pubs/pub40736.html
> section 4.3
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Help wanted: Membrane proxies + Object.freeze() == paradox

[Alex Vincent]

Full details are at https://github.com/ajvincent/es7-membrane/issues/79 ,
which is where I'm hoping to find a solution.

In short:  if

   1. I have a function wetB() and an instance of wetB called wet_b,
   2. I call Object.freeze(wet_b);
   3. I create matching "membrane" proxies for wetB and wet_b named dryB
   and dry_b,

Then:

   - Reflect.get(wetB, "prototype") === Reflect.getPrototypeOf(wet_b)
   - Reflect.get(dryB, "prototype") !== Reflect.getPrototypeOf(dry_b)

This is a paradox:  I claim that what's true on the "wet" object graph
should be true on the "dry" object graph.

Please, if you can offer help on this to fix the sample code I've posted,
or if you can confirm that my claim above is incorrect and never can be
correct, I'd appreciate it.

Alex Vincent

Hayward, CA, USA

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proxies fail comparison operator

[Alex Vincent]

You really don't *want* proxies to equal their underlying objects:  proxies
can show properties that the underlying object doesn't have, hide
properties that the underlying object does have, alter the appearance of
other proxies, etc.

What you probably want is to never deal with the underlying object in the
first place, unless you absolutely have to.  That's why you'd create a
proxy anyway...

Have you heard about membranes?  I've talked about them on this list
recently, as have several others over the years...

I don't intend to toot my own horn too much, but you might want to check
out my es7-membrane project:
https://github.com/ajvincent/es7-membrane/

Alex

From: Michael Lewis 
> To: es-discuss@mozilla.org
> Cc:
> Bcc:
> Date: Thu, 30 Mar 2017 13:50:07 -0500
> Subject: Proxies fail comparison operator
> Hello community,
>
> The proxy is almost an identical to the underlying object, but it* fails
> a comparison check with the underlying object.*
>
> This means that if anyone gets a reference to the underlying object before
> it is proxied, then we have a problem.  For example:
>
> var obj = {};
> var proxy = new Proxy(obj, {});
> obj == proxy; // false
>
> *Isn't the purpose of the proxy to be exchanged with the original**,
> without any negative side effects?  *Maybe that's not the intended use
> case, but it's a useful one.  And, besides the comparison, I can't think of
> any other "negative side effects".
>
> It seems like the Proxy could have a *comparison trap*.  The comparison
> could pass by default, and you could use the trap if you wanted to make
> `proxy == obj` fail.
>
> Also, a slight tangent: it would be awesome if you could *skip debugging
> proxy traps when stepping through code.  *When you proxy both `get` and
> `apply` for all objects/methods, you have 10x the work when trying to step
> through your code.
>
> I just subscribed to this list.  Is this an appropriate venue for this
> type of inquiry?  I appreciate any feedback.
>
>
>
> Thanks!
>
> Michael
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: es7-membrane: A new ECMAScript 2016 Membrane implementation

[Alex Vincent]

A follow-up to my earlier posts:  es7-membrane has reached version 0.7,
which features a practical whitelist capability, multiple object graphs,
and support for ES6 symbols as the "names" of object graphs.

I'd still like to find some volunteer contributors.  Also, a colleague on
the SES task force suggested the es7-membrane project's tests might be
ported to make a good integration test for test-262 (as opposed to unit
tests)...

https://alexvincent.us/blog/?p=922
https://github.com/ajvincent/es7-membrane

On Mon, Aug 22, 2016 at 9:53 PM, Alex Vincent  wrote:

> I have a new ECMAScript membrane implementation [1], which I will maintain
> and use in a professional capacity, and which I’m looking for lots of help
> with in the form of code reviews and API design advice.
>
> I wrote a lengthier post on my weblog [2], with more details of what I
> hope to get out of it.  From this group, I'm hoping to get some API design
> advice, and suggestions on how to make it even more ECMAScript-friendly and
> follow the rules of ES6 modules.
>
> Side note, specifically for this group:  After reading Dr. Rauschmeyer's
> chapter on ES6 modules [3], I tried writing the following:
> try {
>   import ...
> }
> catch (e) {
>   // do something else
> }
>
> But that resulted in a syntax error for import not being the first line of
> the script.  I really wonder why it's illegal to wrap the import statement
> in a try block...
>
> [1] https://github.com/ajvincent/es7-membrane
> [2] https://alexvincent.us/blog/?p=908
> [3] http://exploringjs.com/es6/ch_modules.html
>
> Thank you for both your time and your good work on the ES6 specification
> and implementations!
>
>
>
> Alex Vincent
> Hayward, CA
>
> --
> "The first step in confirming there is a bug in someone else's work is
> confirming there are no bugs in your own."
> -- Alexander J. Vincent, June 30, 2001
>



-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Is Narcissus dead?

[Alex Vincent]

I remembered the Narcissus (JS engine implemented in JS) project, and was
thinking, "wouldn't it be nice to prototype my Symbol.operator idea [1] in
that?"  Then I looked on Github, and saw that Mozilla's Narcissus
repository hasn't had a commit in over five years. [2]

Ouch.  With ES6 and now ES7 released, I am curious as to whether someone
has a fork out there which implements the recent standards.  I couldn't
find one...

Granted, proxies have changed a lot in the last few years, so Zaphod, which
made scripts run in Narcissus, would need a serious update...

[1] https://esdiscuss.org/topic/operator-overloading-via-symbol-arithmetic
[2] https://github.com/mozilla/narcissus

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Operator overloading, via Symbol.arithmetic?

[Alex Vincent]

Regarding operator overloading, I had a new idea last night.

Suppose we could express arithmetic operations on an object via a
"well-defined" symbol (using the specification's terminology), named
Symbol.arithmetic:

let a = new Fraction(1, 2); // 1/2
let b = new Complex(2, 5); // 2 + 5i

a * b: function()
{
let ta = (typeof a == "number") || (a instanceof Number);
let tb = (typeof b == "number") || (b instanceof Number);

if (ta && tb) {
// just do the regular operation, as defined in ES7, section 12.7.3 (yawn)
}
if (typeof a[Symbol.arithmetic] == "function") {
return a[Symbol.arithmetic](a, "*", b);
}
if (typeof b[Symbol.arithmetic] == "function") {
return b[Symbol.arithmetic](a, "*", b);
}
return NaN;
}

This algorithm would be compatible, I think, with existing JavaScript:
(new Object) * (new Object) == NaN right now.  This supports the
traditional arithmetic and comparison operators, and the new ** operator
rather well.

For unary operators + and -, just make the first argument 0, and let the
third argument be the object.

For the assignment operator, only run the left-hand assignment test, and
perhaps treat it like a property definition (returning truthy means the
operation succeeded, false means it failed).

I am well aware that this doesn't cover other operators, like [].  This is
just a starting suggestion.

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Membranes: filtering own properties, questions on ES7 intent

[Alex Vincent]

Hello, everyone.  Now that the quarter at my local university is over,
I'm working on my es7-membrane project again.  [1]

In implementing "filterOwnKeys", I realized I have wandered into a
couple of open questions, where I do not know from the ES7
specification what the desirable behavior is.  I have written tests
for these two cases that I've discovered so far, but I currently have
them disabled.  Hopefully this mailing list can provide me with some
insight.

The filterOwnKeys API is pretty much as it sounds:  you name the
object graph and object you want filtering to apply to, and pass in an
array filtering function.

The first "unclear" testcase asks, "Reflect.defineOwnProperty(dry,
'blacklisted', desc) should return what?" [2]  The question there is,
"should didSet be true because we set a value on the wet object graph,
or false because we failed to set a value on the dry object graph?"

The second "unclear" testcase examines "Deleting a blacklisted
property defined on the original target via the dry graph".  [2]  In
this case, defining the property worked (albeit invisibly to the dry
graph), but it's unclear if a delete operation on the property should
propagate.

These questions, by the way, should be explicitly handled when the
membrane customer invokes other modification API's -
"requireLocalDelete" and "storeUnknownAsLocal", specifically.  The
three modification API's, plus a "proxy creation observer" API, will
combine to form a practical whitelisting example.  I am therefore
explicitly asking about what should the proxy API should do in an
otherwise perfect-mirror membrane implementation.

Advice, and debate, is most welcome!

Alex Vincent
Hayward, CA, U.S.A.


[1] https://github.com/ajvincent/es7-membrane
[2] 
https://github.com/ajvincent/es7-membrane/blob/master/spec/properties/filterOwnKeys.js

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Private members in classes

[Alex Vincent]

Hiding private values is something that I've been thinking a lot about in
my es7-membrane project. [1]  Unfortunately, I've been overloaded with my
full-time job and university courses this quarter, and the soonest I can
return to it will probably be late December.  For about two weeks, until
the next quarter begins.  I'm really overloaded...

[1] https://github.com/ajvincent/es7-membrane/issues/19

Alex Vincent
Hayward, CA, U.S.A.

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

[Alex Vincent]

Based on your feedback, I've filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1300793 .  Thanks for your
help.

On Mon, Sep 5, 2016 at 6:21 PM, Mark S. Miller  wrote:

> Besides those two, the only other reference to
> AddRestrictedFunctionProperties is  international.org/ecma-262/7.0/#sec-createintrinsics> step 12:
>

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

[Alex Vincent]

Ugh!!  It's a trap!  (In the Star Wars sense, not the proxy sense.)

So if all my code is in strict mode, and I get a non-strict code function
to shadow as Tom and I were talking about in another thread... how do I
even test for that if my code is either consistently strict or consistently
non-strict?

On Mon, Sep 5, 2016 at 6:21 PM, Mark S. Miller  wrote:

> Besides those two, the only other reference to
> AddRestrictedFunctionProperties is <http://www.ecma-
> international.org/ecma-262/7.0/#sec-createintrinsics> step 12:
>
> 12. Perform AddRestrictedFunctionProperties
> <http://www.ecma-international.org/ecma-262/7.0/#sec-addrestrictedfunctionproperties>
> (funcProto, realmRec).
>
> So .caller and .arguments must now exist as poisoned on (the intrinsic
> normally bound to) Function.prototype . So, besides Function.prototype,
> they may only appear on old-style sloppy functions; nowhere else.
>
>
>
> On Mon, Sep 5, 2016 at 6:09 PM, Caitlin Potter 
> wrote:
>
>> The part that matters here is in annex B: http://www.ecma-internation
>> al.org/ecma-262/7.0/#sec-forbidden-extensions
>>
>> This forbids functions in strict code from having own properties "caller"
>> or "arguments". Newer function kinds have these restrictions in sloppy mode.
>>
>> AddRestricted... adds the accessor which makes getting/setting "caller"
>> or "arguments" throw, but is per spec only performed on intrinsics (like
>> %FunctionPrototype%).
>>
>> So unfortunately, this is something your membrane would need to be aware
>> of and work around. Mozilla's approach violates ECMAScript's forbidden
>> extensions and can't be considered "correct"
>>
>
> This result by itself does not demonstrate that Mozilla or v8 are either
> conformant or non-conformant. By the spec, A must not have its own .caller
> and .arguments -- it must only inherit these from Function.prototype. B,
> being sloppy, may or may not.
>
>
>
>>
>>
>> Sent from my iPhone
>> On Sep 5, 2016, at 8:54 PM, Alex Vincent  wrote:
>>
>> 
>> "use strict"
>> function A() {}
>> 
>> 
>> function B() {}
>> 
>> 
>> window.onload = function() {
>> let a = Reflect.ownKeys(A);
>> let b = Reflect.ownKeys(B);
>> document.getElementById("output").value = (a.includes("arguments")
>> === b.includes("arguments"));
>> }
>> 
>>
>> Mozilla Firefox reports true. Google Chrome and node.js report false.
>> Which one is correct?
>>
>> I looked through Mozilla's Bugzilla, Google Chrome's Monorail, and the
>> ES7 spec to try figuring this out.  The closest I could get was section
>> 9.2.7 of the ES7 spec. [1]
>>
>> Right now I have an inadvertent mix of strict code / non-strict code in
>> my membrane, and this difference is causing my most recent patch to fail
>> tests in nodejs and Google Chrome, and to pass in Mozilla Firefox.  In
>> Chrome and nodejs, I get:
>>
>> TypeError: 'ownKeys' on proxy: trap result did not include 'arguments'
>>
>> If it turns out Google & nodejs are correct, this could be an issue going
>> forward:  I can't control whether my membrane library's users are running
>> strict mode code or not... likewise, I don't know if my code should be
>> consistently strict mode or consistently non-strict.  (I feel that a mix is
>> not good, except for finding bugs like this...)
>>
>> My apologies for treating this list as a help forum, but I'm just not
>> sure where else to go...
>>
>> [1] http://www.ecma-international.org/ecma-262/7.0/#sec-addrestr
>> ictedfunctionproperties
>> --
>> "The first step in confirming there is a bug in someone else's work is
>> confirming there are no bugs in your own."
>> -- Alexander J. Vincent, June 30, 2001
>>
>> ___
>> 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
>



-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

[Alex Vincent]

"use strict"
function A() {}


function B() {}


window.onload = function() {
let a = Reflect.ownKeys(A);
let b = Reflect.ownKeys(B);
document.getElementById("output").value = (a.includes("arguments") ===
b.includes("arguments"));
}


Mozilla Firefox reports true. Google Chrome and node.js report false.
Which one is correct?

I looked through Mozilla's Bugzilla, Google Chrome's Monorail, and the ES7
spec to try figuring this out.  The closest I could get was section 9.2.7
of the ES7 spec. [1]

Right now I have an inadvertent mix of strict code / non-strict code in my
membrane, and this difference is causing my most recent patch to fail tests
in nodejs and Google Chrome, and to pass in Mozilla Firefox.  In Chrome and
nodejs, I get:

TypeError: 'ownKeys' on proxy: trap result did not include 'arguments'

If it turns out Google & nodejs are correct, this could be an issue going
forward:  I can't control whether my membrane library's users are running
strict mode code or not... likewise, I don't know if my code should be
consistently strict mode or consistently non-strict.  (I feel that a mix is
not good, except for finding bugs like this...)

My apologies for treating this list as a help forum, but I'm just not sure
where else to go...

[1]
http://www.ecma-international.org/ecma-262/7.0/#sec-addrestrictedfunctionproperties
-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proxies and preventExtensions: how to avoid inconsistency in a membrane?

[Alex Vincent]

On Sun, Sep 4, 2016 at 1:14 PM, Tom Van Cutsem  wrote:

> Essentially, if you want to implement a membrane that works in the face of
> ES invariants, you need to use the "shadow target" technique where the
> membrane proxy is not directly targeting the "real" target object but
> instead a "dummy" target object that it can use to be more flexible in what
> it can answer. It seems that is more or less the solution you stumbled
> upon. See  examples/generic_membrane.js> for a membrane implementation that works
> this way.
>

Ah, nuts.  I suspected that might be the case.  Well, it's ugly but it *is*
doable within the rules, and I already have an appropriate code point to
make that work out.  (Nice that the first argument of each trap is the
proxy target.)

Regarding .hasBeenRevoked, yes, I get that too.  The revoke function from
Proxy.revocable() handles only the proxy itself, no administration of
metadata around that.  Oh, well, it was worth a shot.

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proxies and preventExtensions: how to avoid inconsistency in a membrane?

[Alex Vincent]

An ES7 invariant is forcing me to consider some truly nasty hacks for
my Membrane implementation... and I'm only getting started with practical
use-cases.  So I want the ECMAScript language contributors to consider the
same, and maybe offer something I haven't thought of.  :-)

Consider the following code:

var x = { property1: true};
var extra = {
  isExtra: true
};
var extraDesc = {
  value: extra,
  writable: true,
  enumerable: true,
  configurable: true
};
var h = {
  ownKeys: function(target) {
return Reflect.ownKeys(target).concat("extra");
  },

  getOwnPropertyDescriptor: function(target, propName) {
if (propName === "extra")
  return extraDesc;
return Reflect.getOwnPropertyDescriptor(target, propName);
  }
};

var p = new Proxy(x, h);
Reflect.ownKeys(p); /* ["property1", "extra"] */

Object.preventExtensions(x); // this works fine

Reflect.ownKeys(p); // throws an error

The ES7 spec requires this behavior:
http://www.ecma-international.org/ecma-262/7.0/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys
(see the very last invariant under the note following the algorithm)

A couple weeks ago, I wrote to this mailing list to announce a membrane
implementation under development.  One main reason for a membrane is that
you can hand untrusted code a set of proxies from one "object graph" and
protect the actual implementation from reaching the untrusted zone.  So the
first use case I came up with is "allow untrusted code to define properties
that never make it to the protected objects."  The reason why is to save
clutter on the implementation (particularly for debugging), while giving
the untrusted code more freedom.  (I have many, many more use cases.  This
was just the simplest.)

If the protected objects are not extensible from the beginning, by rule,
neither can any proxy be that uses the protected objects as proxy targets.
That's irritating, but not a genuine problem.  The real problem is when the
target starts out extensible... and then, through no action of the
untrusted code or proxies such code is given, the proxy target's
extensibility ends.

Suddenly, the proxy for that target is broken:

   - ownKeys and getOwnPropertyDescriptor used to report additional local
   properties but are now forbidden from doing so
   - the extra properties came from untrusted code, so now the untrusted
   code can't get those properties back: instead errors are thrown

Revoking the broken proxy has even more side effects:

   - *All* of the proxy's properties are inaccessible - and trying to
   access them throws errors
   - Other proxies which refer to that proxy by property name have no way
   of detecting the proxy is revoked

One alternative I came up with is equally undesirable:  generating an
artificial target for each proxy that, through a WeakMap, refer to the
desired targets.

   - A proxy can't be called as a function (or a constructor) unless the
   target is a function. (More precisely, it can't be called unless the target
   has a "[[Callable]]" attribute, so a Function() instance might work.)
   - An extensible proxy that refers to a non-extensible object must have
   an actual target that is extensible, and (probably via a WeakMap) allows
   the handler to get the real target.
   - For m object graphs to n lockable objects, you would need (m * n)
   non-primitive values that have to be defined so that the proxies can't be
   locked out of having their own properties that don't propagate to the
   original objects...

In fact, the way my membrane is written *now*, it is vulnerable to
Object.preventExtensions() pulling the rug out from under it in this
manner.  (I have a property I expose in a similar manner to the example
above, for debugging and testing purposes only.  It will eventually go
away.)

So the options I can see, under the rules, are either a whole bunch of
carefully-chosen artificial targets or documentation that says "you can't
provide local properties and disable the underlying objects'
extensibility."  I could go for a third, hybrid option which is
opt-in-to-extensible-targets, again with documentation.

I'm writing to ask the following:

   1. Are there other options for the given problem that I am not seeing?
   2. Could the existing ProxyHandler part of the spec be extended, so that
   in the future I could override that invariant (and others, yet
   undetermined) explicitly?
   3. Could there be a Proxy.hasBeenRevoked(proxy) method?

(I'm aware I could use some internal tracking mechanism to detect when a
reference from one Proxy to another, previously-defined one must be
broken... but that defeats the purpose of a Membrane providing proxies for
use in the first place.)
-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/li

es7-membrane: A new ECMAScript 2016 Membrane implementation

[Alex Vincent]

I have a new ECMAScript membrane implementation [1], which I will maintain
and use in a professional capacity, and which I’m looking for lots of help
with in the form of code reviews and API design advice.

I wrote a lengthier post on my weblog [2], with more details of what I hope
to get out of it.  From this group, I'm hoping to get some API design
advice, and suggestions on how to make it even more ECMAScript-friendly and
follow the rules of ES6 modules.

Side note, specifically for this group:  After reading Dr. Rauschmeyer's
chapter on ES6 modules [3], I tried writing the following:
try {
  import ...
}
catch (e) {
  // do something else
}

But that resulted in a syntax error for import not being the first line of
the script.  I really wonder why it's illegal to wrap the import statement
in a try block...

[1] https://github.com/ajvincent/es7-membrane
[2] https://alexvincent.us/blog/?p=908
[3] http://exploringjs.com/es6/ch_modules.html

Thank you for both your time and your good work on the ES6 specification
and implementations!



Alex Vincent
Hayward, CA

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Exporting ES tests to a webpage environment?

[Alex Vincent]

I'm wondering how I could test a custom implementation of a ECMAScript
standard API in a web browser, against existing test suites that might not
run in a browser.



I've been re-exploring implementing a Membrane, which Tom van Cutsem
introduced to me through blogs and this mailing list a few years ago.
(Thanks, Tom!)  So at the moment, I'm working on implementing my own module
code based on the latest published and approved standards, which are
slightly different than what Tom had to work with.

Along the way, I happily discovered the Reflect object's API matches the
ProxyHandler's API.  That can't be by accident. I suspect SpiderMonkey's
Reflect implementation is probably very close to the standard, given the
usual high quality of their work and good number of tests they have in
their codebase. [1]  That, plus the TC39 tests, [2] give me confidence that
the native Reflect implementation I use in a Firefox-derived application
will be quite good.  Combined with WeakMap, it should make a basic Membrane
implementation relatively easy.

With that said, I think I will run into complications when I try to
introduce other ideas, such as hiding properties.  So I may have to write a
custom Reflect implementation.  That implementation will in some cases just
call the native Reflect API.  But in other cases I suspect I will need a
little more detailed information, like "Which object in the prototype chain
actually implements that named property?"

Plus, I will probably have some debug-logging to do, as Firefox's debugger
doesn't like to step through proxy handler code.  (I have to look for an
existing bug on that, or file one.  It's easy to reproduce.)



The good news is, I suspect I can run a custom Reflect against existing
code, loaded in a webpage, by wrapping it in function(Reflect) { ... }.
The bad news is, neither test suite linked above makes it obvious how to do
so.  That's what I'm looking for advice on.

Alex Vincent
Hayward, CA, U.S.A.

[1] https://dxr.mozilla.org/mozilla-esr45/source/js/src/tests/ecma_6/Reflect
[2] https://github.com/tc39/test262/tree/master/test/built-ins/Reflect

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Alex Vincent]

On Wed, Jul 23, 2014 at 2:00 PM, Michael Haufe 
wrote:

> Array.prototype.removeAt(index);
> Array.prototype.remove(element);
>

We already have an equivalent of removeAt:  Array.prototype.splice(index,
1).  My concern about remove still stands.

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Alex Vincent]

On Wed, Jul 23, 2014 at 11:18 AM,  wrote:

> So too, for cases of removing an item, would Array.prototype.remove(v)
> show clear intent.
>

I would actually raise a concern about that method.  Suppose v shows up in
the array more than once.  Do you remove the first appearance, the last, or
all of them?

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RegExp spec question

[Alex Vincent]

r = /\u0020+$/g; p = r.exec("  "); q = r.exec("  "); JSON.stringify([p, q])
// "[[\"  \"],null]"

Why does calling exec the second time generate null?  When I try the
regular expression without the /g flag, I get:
// "[[\"  \"],[\"  \"]]"



-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Value types versus .valueOf

[Alex Vincent]

I like the idea of value types, but I wonder if, for terminating decimal
numbers, the .valueOf() method from Object.prototype might be sufficient
for many operations.

Example:

function SmallDecimal(k) {
this.__value__ = k;
}

SmallDecimal.prototype.valueOf = function() {
return this.__value__.toString(10);
}

var x = new SmallDecimal(2);
var y = new SmallDecimal(3);
[x < y, x > y, x == y, x <= y, x >= y, x != y]

/*
true,false,false,true,false,true
*/

I still want to see value types go forward:  in the above example, x + y
would result in "23", where x - y === -1.  Perhaps .valueOf could be used
in testing simple value types implementations.
-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

SortedArray in JavaScript?

[Alex Vincent]

Hi, folks.  After a year of computer science courses (yay for learning
fundamentals), I've been thinking about arrays and their indexOf() method,
and wondering:  why don't we have an array type that sorts the items for us
in JavaScript?

(By the way, I love the Map & Set implementations in Firefox.  Very, very
handy.)

Because arrays in JS are assumed to be unsorted, indexOf is an O(n)
operation.  But if I have an array of values, and use a simple comparator
function, indexOf becomes O(log n), plus whatever the invocation time is
for the comparator.

In the simplest cases, I'm sorting numbers or strings, which wouldn't need
a fancy comparator function.  If I'm sorting objects, I can write my
comparator function just like I would for Array.sort.

Many of the methods for manipulating arrays would go away (unshift, shift,
push, pop, splice).  There would also be a need to add .has(), .set(),
.remove() methods, probably (like a Map).

I'm sure I'm just repeating the obvious now, so I'm wondering if it would
be worth adding to the language in some form.  I'm well aware it would be
easy to implement in JavaScript, but would a JS-based implementation be
faster than a native one?

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.filter: max number of matches?

[Alex Vincent]

The some method, as currently implemented, isn't truly better.
Mathematically, I think Array.prototype.some would be equivalent to my
suggested Array.prototype.filter(callback, thisObj, 1);

On Tue, Nov 13, 2012 at 12:33 PM, Brendan Eich  wrote:

> Andrea Giammarchi wrote:
>
>> wait, I might have misunderstood your problem ... so you want to stop
>> iterating, right ?
>>
>> When that is the case, you can simply drop the iteration like this:
>>
>> myArray.slice().filter(**function (value, index, original) {
>>   // do your stuff
>>   if (conditionSatisfied) {
>> original.length = 0;
>>   }
>> });
>>
>> there, you can break the iteration as easy as that :-)
>>
>
> Making a copy and then mutating its length seems worse than using some,
> though.
>
> /be
>
>


-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Array.filter: max number of matches?

[Alex Vincent]

I've been wondering for a while if it would be a good idea to add an
argument to Array.prototype.filter, for a maximum number of matches.  For
example, if I have a thousand-element array and I only want three matches,
it might make sense to truncate the search after the third match.

Put another way:  if I want an intersection between two arrays treated as
sets, and one array has only three members, then once I've found matches
for those three, it really doesn't make sense to keep iterating.

Thoughts, anyone?

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

[Alex Vincent]

> -- Forwarded message --
> From: Erik Arvidsson 
> To: es-discuss@mozilla.org
> Cc:
> Date: Thu, 7 Jun 2012 11:37:41 -0700
> Subject: Error stack
> I wrote a new strawman for Error stack which is now available in some
> form in all major browser (if betas are considered).
>
> http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
>
> Feedback wanted.
>

As the person who originally proposed the stack property to Mozilla over
ten years ago, I am absolutely thrilled to see this as a strawman on
Harmony.  In any form.

For reference, the original bug is at
https://bugzilla.mozilla.org/show_bug.cgi?id=123177 .

The only thing I might ask is to keep the ability to alter the stack - in a
controlled way.  Specifically, I've had occasion to want to remove the
first two or three frames of an error stack, because I was implementing an
assert() function.  When the assert failed, I wanted the stack to start at
the actual line of the assert call, instead of a couple of lines away (new
Error(), then the assert function, and then the caller of assert).  That
said, I'd understand if the Harmony working group rejected this and
required the property be read-only and never changeable.

Alex Vincent
-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Harmony helpwanted: Proxy, Map discrepancy between V8 and SpiderMonkey

[Alex Vincent]

https://www.alexvincent.us/temp/ProxyCtor/V8-SpiderMonkey-test.html

I reduced the testcase quite severely.  It's a combination between Proxy
and WeakMap.  I store the proxy as a key for the WeakMap, and then expect
to get back that proxy through Object.getPrototypeOf.

On Tue, Mar 20, 2012 at 7:29 AM, Andreas Rossberg wrote:

> On 20 March 2012 08:18, Alex Vincent  wrote:
>
>> Hi, everyone.  I've been tinkering around with Harmony's Proxy and
>> WeakMap implementations, and I've run into a problem.  A Jasmine test which
>> works fine in Mozilla Firefox Aurora builds throws an exception in Google
>> Chrome Dev builds, with the experimental JavaScript features enabled.
>>
>> I really need some help in identifying whether the bug is in Aurora,
>> Chrome, or in my own code.  I wrote all of the JavaScript code in the
>> project, and to my knowledge none of it is browser- or engine-specific; it
>> should all conform to Harmony and ECMAScript standards unless I have a bug
>> in my code.
>>
>
> Proxies are rather new, so it might very well be a bug in V8. There might
> also be minor implementation differences between the two systems, since the
> proxy spec wasn't entirely complete yet and has changed in some details,
> even before the advent of direct proxies.
>
> I would need a small enough test case to verify that. Is there a chance
> that you can narrow down the exact point where the behaviours of Firefox
> and Chrome start to differ unexpectedly? For example, with some printf
> debugging?
>
> /Andreas
>
>


-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Harmony helpwanted: Proxy, Map discrepancy between V8 and SpiderMonkey

[Alex Vincent]

Hi, everyone.  I've been tinkering around with Harmony's Proxy and WeakMap
implementations, and I've run into a problem.  A Jasmine test which works
fine in Mozilla Firefox Aurora builds throws an exception in Google Chrome
Dev builds, with the experimental JavaScript features enabled.

I really need some help in identifying whether the bug is in Aurora,
Chrome, or in my own code.  I wrote all of the JavaScript code in the
project, and to my knowledge none of it is browser- or engine-specific; it
should all conform to Harmony and ECMAScript standards unless I have a bug
in my code.

The concept I'm working on is using Proxy to create prototype objects for
constructor functions, and using a membrane like Tom van Cutsem's to
isolate private properties from public ones.

Steps to reproduce are below.  I have partially reduced my testcase so that
other parts of my project are not run as part of the test, and no Makefile
or other scripting commands are necessary.

Terminal commands:
hg clone --branch ProxyConstructorTest
http://code.google.com/p/dimensionalmap test-proto-membrane
cd test-proto-membrane/
hg update --rev 5992f4c09a38

Open V8-SpiderMonkey-test.html in Mozilla Firefox Aurora and in Google
Chrome Dev 19.

In FF Aurora, all tests pass.
In GC Dev:
TypeError: Object.getOwnPropertyDescriptor called on non-object
at Function.getOwnPropertyDescriptor (native)
at Object.getDesiredPropertyOwner
(file:///home/ajvincent/repositories/test-proto-membrane/ProtoMembrane/Membrane.js:59:34)
at Object.foo
(file:///home/ajvincent/repositories/test-proto-membrane/ProtoMembrane/Membrane.js:82:31)
at [object Object].
(file:///home/ajvincent/repositories/test-proto-membrane/spec/ProtoMembrane.js:94:21)

The function executing is in ProtoMembrane/Membrane.js:

  getDesiredPropertyOwner: function(originalThis, name) {
var _thisObj = this.getPrivate(originalThis);
if (_thisObj == originalThis) {
  while (_thisObj &&
!Object.getOwnPropertyDescriptor(Object.getPrototypeOf(_thisObj), name)) {
_thisObj = Object.getPrototypeOf(_thisObj);
  }
}
return _thisObj;
  },

In Aurora, _thisObj != originalThis, so it just moves on.
In GC Dev, _thisObj == originalThis, and on the second iteration of the
while loop, Object.getPrototypeOf(_thisObj) is null.
Object.getOwnPropertyDescriptor(null, "foo"); throws the TypeError.

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss