Re: An update on Object.observe

[Andrea Giammarchi]

Just to be clear:

  1. I am very happy O.o is gone
  2. in my experience it's repeatedly clear that whatever proposal that
cannot be polyfilled will have hard time to be widely adopted.

As example, O.o has never been in other browsers so, unless you are
targeting Chrome and Chrome only, it's kinda a bad choice. Maybe it would
have been adopted more if it was cross platform?

Who knows, and let's move forward!

Best Regards



On Tue, Nov 3, 2015 at 11:26 AM, Alexander Jones  wrote:

> In my opinion, the fundamental record type we build our JS on should be
> getting dumber, not smarter. It feels inappropriate to be piling more
> difficult-to-reason-about mechanisms on top before reeling in exotic host
> objects. With Proxy out of the bag, I'm not so hopeful for the humble
> Object anymore.
>
>
> On Tuesday, 3 November 2015, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Sure thing, meanwhile polymer or other libraries need to pollute getters
>> and setters and the rest of the web have been trying to polyfill it for at
>> least 6 years now *
>>
>> The reason is not widely "abused" is that it never made it as standard
>> and as it is feels like an outdated spec. Proxy would give us that and much
>> more, unfortunately proxies do not play so well cross environment. For
>> instance, I've tried to use them in GJS ( Gtk+3 JavaScript bindings ) and
>> while Object.prototype.watch always works, proxied GObjects fail to be used
>> like these were just GObjects.
>>
>> That might be a specific env problem though, but having a way to watch
>> properties, specially in two ways bindings scenarios, is a very needed
>> common thing.
>> As example, in DOMClass I'm replacing native getters/setters to be
>> notified about changes, it doesn't feel right even if it works.
>>
>> All this is over-off-topic though, so I might just stop.
>>
>> Best Regards
>>
>>
>>
>> * just few examples since 2009
>> https://gist.github.com/eligrey/384583
>> https://gist.github.com/adriengibrat/b0ee333dc1b058a22b66
>> question in SO
>> http://stackoverflow.com/questions/1029241/javascript-object-watch-for-all-browsers
>> http://deploytonenyures.blogspot.co.uk/2013/02/objectwatch-polyfill.html
>>
>> https://code.google.com/p/chtor/source/browse/chtor/chrome/js/object-watch.js?spec=svn2c00820d48169bb678a00447e295fb31dcf448ed=2c00820d48169bb678a00447e295fb31dcf448ed
>>
>> yes, I've done that too
>> in 2009
>> http://webreflection.blogspot.co.uk/2009/01/internet-explorer-object-watch.html
>> and recently https://gist.github.com/WebReflection/366dc38574dc526308b5
>>
>>
>>
>> On Tue, Nov 3, 2015 at 2:11 AM, Boris Zbarsky  wrote:
>>
>>> On 11/2/15 4:55 PM, Andrea Giammarchi wrote:
>>>
 I agree with Benoit and I think there is a reason
 `Object.prototype.watch` is still in Firefox and  won't go away any time
 soon

>>>
>>> As far as I know the only reason it's there and hasn't been removed is
>>> because it's used to implement debugger watchpoints [1].  And the only
>>> reason it's web-exposed is because SpiderMonkey has not prioritized being
>>> able to expose APIs to privileged code but not the web (something that
>>> think should get fixed).
>>>
>>> -Boris
>>>
>>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=934669
>>>
>>> ___
>>> 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

Re: An update on Object.observe

[Andrea Giammarchi]

Sure thing, meanwhile polymer or other libraries need to pollute getters
and setters and the rest of the web have been trying to polyfill it for at
least 6 years now *

The reason is not widely "abused" is that it never made it as standard and
as it is feels like an outdated spec. Proxy would give us that and much
more, unfortunately proxies do not play so well cross environment. For
instance, I've tried to use them in GJS ( Gtk+3 JavaScript bindings ) and
while Object.prototype.watch always works, proxied GObjects fail to be used
like these were just GObjects.

That might be a specific env problem though, but having a way to watch
properties, specially in two ways bindings scenarios, is a very needed
common thing.
As example, in DOMClass I'm replacing native getters/setters to be notified
about changes, it doesn't feel right even if it works.

All this is over-off-topic though, so I might just stop.

Best Regards



* just few examples since 2009
https://gist.github.com/eligrey/384583
https://gist.github.com/adriengibrat/b0ee333dc1b058a22b66
question in SO
http://stackoverflow.com/questions/1029241/javascript-object-watch-for-all-browsers
http://deploytonenyures.blogspot.co.uk/2013/02/objectwatch-polyfill.html
https://code.google.com/p/chtor/source/browse/chtor/chrome/js/object-watch.js?spec=svn2c00820d48169bb678a00447e295fb31dcf448ed=2c00820d48169bb678a00447e295fb31dcf448ed

yes, I've done that too
in 2009
http://webreflection.blogspot.co.uk/2009/01/internet-explorer-object-watch.html
and recently https://gist.github.com/WebReflection/366dc38574dc526308b5



On Tue, Nov 3, 2015 at 2:11 AM, Boris Zbarsky  wrote:

> On 11/2/15 4:55 PM, Andrea Giammarchi wrote:
>
>> I agree with Benoit and I think there is a reason
>> `Object.prototype.watch` is still in Firefox and  won't go away any time
>> soon
>>
>
> As far as I know the only reason it's there and hasn't been removed is
> because it's used to implement debugger watchpoints [1].  And the only
> reason it's web-exposed is because SpiderMonkey has not prioritized being
> able to expose APIs to privileged code but not the web (something that
> think should get fixed).
>
> -Boris
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=934669
>
> ___
> 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

Re: An update on Object.observe

[Mark S. Miller]

On Tue, Nov 3, 2015 at 11:27 AM, lycheeJS Engine <
lycheejs+esdisc...@gmail.com> wrote:

> I think we still need Object.observe as a specification to implement
> proper sandboxing of feature-detecting closures.
>

What do you mean by "sandbox"?

(I was not able to make sense of the rest of this message using my normal
understanding of "sandbox".)




>
> For example, in lycheeJS we have a sandboxing system that can inject
> definitions (and their variants) at runtime, replaces them intelligently at
> runtime. The definition closures have, for that purpose, all a supports()
> and exports() method. Both are using a referenced object that is sandboxed.
> The global property therefore is just a reference to a custom object, so
> that we can trace the properties, data types and causes of the errors.
>
> The implementation got stuck because of missing support for ES6 Proxies in
> the wild, but the idea is to use them to figure out if an implementation is
> doing something like window.addEventListener('asdasd') in the background
> and escalating an error up to a delegation handler that figures out what to
> do and what to inject to run it again. It is necessary to not only track
> properties and their data type; we need a feature to track if it was a
> function that threw an error or not.
>
>
> Easy use case:
>
> Imagine a var sandbox = { setTimeout: window.setTimeout }; This would
> throw a context error and we would need that information with proper
> description on what happened in order to isolate setTimeout and inject our
> In-JS Debugger there.
>
> We think Object.observe is an essential feature to have the simulation
> part of this, because we need desperately the capabilities to have a
> in-JS-written Debugger that can find such issues for our training of the
> Graph NN. The execution time aspect of this is a show-stopper if it would
> not be possible.
>
>
> Advanced use case:
>
> We don't use a RendererFactory that is executed once a new Renderer is
> instantiated, we have multiple Renderer implementations for multiple
> platforms available. Each Renderer has its own platform
> (fertilizer)-specific implementation. Those implementations are called
> alternative Definitions.
>
> Each definition has a supports() method that is called once the runtime
> error-determination algorithm tries to inject a new instance of the
> Renderer somewhere or de-reference an old, now slowly running Renderer.
>
> The supports() method can have all kinds of ES5 / ES6 code in order for
> the determination; it is the essential point to determine the capabilities
> of the runtime - at the given execution time, not compile time.
>
> If, for example, the canvas binding in the runtime on Android has problems
> now and throws some errors; there might be a fallback implementation
> available (SDL / OpenGL / GLUT / whatever) and then the Environment sandbox
> updates its dependencies accordingly and tries out "if one of the fallback
> implementation would be supported right now".
>
> Therefore, we think that Object.observe is quite necessary for our
> live-update-and-inject algorithms to determine compatibility problems for
> out-rolled updates _before_ they are applied to have proper feedback for
> our NN on the other peer-side of things.
>
>
> PS:
>
> In case anyone is interested, the problem for which we would need
> Object.observe and ES6 Proxies available, is here:
> https://github.com/Artificial-Engineering/lycheeJS/blob/development-0.9/lychee/source/core/Environment.js#L112
>
>
> But I could be totally all-wrong with this. If the described features are
> possible to be implemented with ES6 Proxies alone, I'm fine with
> deprecating Object.observe and with switching to ES6 Proxies. But the
> features are essential for us to choose ES6/ES7 as a language and I hope
> that others have similar feature requests.
>
> ~Chris
>
> ___
> 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: An update on Object.observe

[Adam Klein]

On Tue, Nov 3, 2015 at 1:25 PM, Coroutines  wrote:

> On Tue, Nov 3, 2015 at 1:24 PM, Adam Klein  wrote:
>
> > Note that O.o didn't help for the "as they happen" case anyway, as
> callbacks
> > were delayed until the end of the turn (same timing as Promise
> resolution).
> > Proxies are required to do synchronous interception.
>
> Would this be similar to .nextTick() in node?  I would still view this
> as much better than polling for changes with a timer :>


Yes, similar to nextTick() (and I agree that's better than polling,
conceptually). But Proxies are strictly more powerful.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Coroutines]

On Tue, Nov 3, 2015 at 1:24 PM, Adam Klein  wrote:

> Note that O.o didn't help for the "as they happen" case anyway, as callbacks
> were delayed until the end of the turn (same timing as Promise resolution).
> Proxies are required to do synchronous interception.

Would this be similar to .nextTick() in node?  I would still view this
as much better than polling for changes with a timer :>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Coroutines]

On Tue, Nov 3, 2015 at 3:26 AM, Alexander Jones  wrote:
> In my opinion, the fundamental record type we build our JS on should be
> getting dumber, not smarter. It feels inappropriate to be piling more
> difficult-to-reason-about mechanisms on top before reeling in exotic host
> objects. With Proxy out of the bag, I'm not so hopeful for the humble Object
> anymore.

As far as I know, without Proxy or Object.observe() there would be no
possible way to watch for changes *as they happen* and directly fire
off an observing function or handler.  You need assistance from the JS
runtime to track stuff like this correctly and efficiently.  The
polyfills for O.o() use timers to watch for changes - changes/accesses
can be missed between polls.  I am happy Proxy is at least staying
around - I was initially freaking out thinking Object.observe() was
the mechanism behind Proxy's magicalness.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Adam Klein]

On Tue, Nov 3, 2015 at 1:18 PM, Coroutines  wrote:

> On Tue, Nov 3, 2015 at 3:26 AM, Alexander Jones  wrote:
> > In my opinion, the fundamental record type we build our JS on should be
> > getting dumber, not smarter. It feels inappropriate to be piling more
> > difficult-to-reason-about mechanisms on top before reeling in exotic host
> > objects. With Proxy out of the bag, I'm not so hopeful for the humble
> Object
> > anymore.
>
> As far as I know, without Proxy or Object.observe() there would be no
> possible way to watch for changes *as they happen* and directly fire
> off an observing function or handler.  You need assistance from the JS
> runtime to track stuff like this correctly and efficiently.  The
> polyfills for O.o() use timers to watch for changes - changes/accesses
> can be missed between polls.  I am happy Proxy is at least staying
> around - I was initially freaking out thinking Object.observe() was
> the mechanism behind Proxy's magicalness.


Note that O.o didn't help for the "as they happen" case anyway, as
callbacks were delayed until the end of the turn (same timing as Promise
resolution). Proxies are required to do synchronous interception.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Coroutines]

Okay, so I've been making a lot of noise on this list in the last few
days about Proxy and Object.observe().  I thought I would try to put
up some example code to show why both should stay, but
Object.observe() usage should be restricted so it's not web-accessible
(debug use only).

  var target = {} // this is the object we want to "observe", either
with Object.observe() or through a Proxy object.
  var p = new Proxy(target, {}); // this is the proxy where we can add
indirection, validation, or simply watch for events as we attempt to
operate on target

With Object.observe() we would be dealing with the same reference,
`target`.  If we used a Proxy we would replace the `target` reference
with that of the proxy to ensure that every operation on `target` is
going through the handling code of the Proxy:

  target = p; // and now only the Proxy holds an internal reference to
the original object (side question: is this accessible through
p.valueOf()?)

Anyway, my issue with Object.observe() is that you can observe
operations on an object from within closures, from references to
`target` that were made before you began observing.

My example is that you have global access to `String`, but a module
usually wraps all its implementation details and private functions in
a (function (){})() and returns either a constructor or an object with
public-facing functions.

(function () {
  var s = String;
  var private = function () { return new s("cat"); }
  var public = function () { return private(); }
  return public;
})()

Please accept this poor example with awful identifiers as code you
might see in the wild.

Now:

Should you be able to Object.observe() String and see that it is being
used to construct "cat" within the private function, within this
closure?

String is accessible and referenced from many places, so observing
that particular object that is very public seems reasonable.  I am on
the fence about if this should be allowed because while String is
quite 'visible', what is happening within that closure should not be.
Closures are used for organization and to hide implementation details
(of course).

The reason I think Proxy does it "right" is because you would need to
replace the reference to String with a Proxy that wraps String before
the closure makes a localized reference to it and exports its public
function.  I think this still respects the "black box" way closures
are used to hide what they do.  Proxy requires setup before references
are made, Object.observe() can begin watching for changes at any time.
This is because a Proxy is a separate object, and therefore has a
separate identity - while Object.observe() works with the original
object.  I want to say that because the closure seals away the
reference to String, that String should not be observable within the
closure - even if you have access to String outside the closure.  If
you wrap String before executing the closure, then you would of course
have the ability - but only if you proxy it before the closure.  To
*me* that would feel correct.

Anyway, I'm going to try to talk less I've been sending too many
messages.  I come from Lua and I love that this functionality exists
in Javascript exists in its own form.  I did a lot of fun things in
Lua so this is pretty personal to me if I want to continue having fun
in JS.

I want Object.observe() to stay for tricky debug situations, but I
think it would break information hiding/encapsulation on the web by
allowing you to observe changes made through existing private
references.  Proxy is what people should use, O.o() can be a private
sexy debug tool?

FIN.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Coroutines]

On Tue, Nov 3, 2015 at 10:08 PM, Isiah Meadows  wrote:
> Proxies can do a better, more thorough job of breaking encapsulation.
>
> ```js
> var log = [];
> String = new Proxy(String, {
>   construct(target, newTarget, args) {
> log.push(args);
> return Reflect.construct(target, newTarget, args);
>   }
> });
>
> (function () {
>   var s = String;
>   var private = function () { return new s("cat"); }
>   var public = function () { return private(); }
>   return public;
> })()
> ```

There's a possibility I am misunderstanding you but this is what I was
trying to say is 'okay'.  If you redefined String to be a proxy before
the closure runs then that seems "legal".

I disagree with Object.observe() because you can call it after the
closure has run and see changes made in String (or another object for
lack of a better example) when you call the exported function.  ...but
now I need to go read up on Reflect.  Be back in a few mins when I
have more slightly inaccurate things to say :o)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Isiah Meadows]

Proxies can do a better, more thorough job of breaking encapsulation.

```js
var log = [];
String = new Proxy(String, {
  construct(target, newTarget, args) {
log.push(args);
return Reflect.construct(target, newTarget, args);
  }
});

(function () {
  var s = String;
  var private = function () { return new s("cat"); }
  var public = function () { return private(); }
  return public;
})()
```

There's no equivalent with Object.observe. I could also redefine String as
a sloppy mode function and use `arguments.callee` or
`Function.prototype.callee` to get the `private` function, which would even
work in ES3. There's ways to break encapsulation already, that don't
involve Object.observe. And you can't observe references purely contained
within a closure.

On Wed, Nov 4, 2015, 00:51 Coroutines  wrote:

> Okay, so I've been making a lot of noise on this list in the last few
> days about Proxy and Object.observe().  I thought I would try to put
> up some example code to show why both should stay, but
> Object.observe() usage should be restricted so it's not web-accessible
> (debug use only).
>
>   var target = {} // this is the object we want to "observe", either
> with Object.observe() or through a Proxy object.
>   var p = new Proxy(target, {}); // this is the proxy where we can add
> indirection, validation, or simply watch for events as we attempt to
> operate on target
>
> With Object.observe() we would be dealing with the same reference,
> `target`.  If we used a Proxy we would replace the `target` reference
> with that of the proxy to ensure that every operation on `target` is
> going through the handling code of the Proxy:
>
>   target = p; // and now only the Proxy holds an internal reference to
> the original object (side question: is this accessible through
> p.valueOf()?)
>
> Anyway, my issue with Object.observe() is that you can observe
> operations on an object from within closures, from references to
> `target` that were made before you began observing.
>
> My example is that you have global access to `String`, but a module
> usually wraps all its implementation details and private functions in
> a (function (){})() and returns either a constructor or an object with
> public-facing functions.
>
> (function () {
>   var s = String;
>   var private = function () { return new s("cat"); }
>   var public = function () { return private(); }
>   return public;
> })()
>
> Please accept this poor example with awful identifiers as code you
> might see in the wild.
>
> Now:
>
> Should you be able to Object.observe() String and see that it is being
> used to construct "cat" within the private function, within this
> closure?
>
> String is accessible and referenced from many places, so observing
> that particular object that is very public seems reasonable.  I am on
> the fence about if this should be allowed because while String is
> quite 'visible', what is happening within that closure should not be.
> Closures are used for organization and to hide implementation details
> (of course).
>
> The reason I think Proxy does it "right" is because you would need to
> replace the reference to String with a Proxy that wraps String before
> the closure makes a localized reference to it and exports its public
> function.  I think this still respects the "black box" way closures
> are used to hide what they do.  Proxy requires setup before references
> are made, Object.observe() can begin watching for changes at any time.
> This is because a Proxy is a separate object, and therefore has a
> separate identity - while Object.observe() works with the original
> object.  I want to say that because the closure seals away the
> reference to String, that String should not be observable within the
> closure - even if you have access to String outside the closure.  If
> you wrap String before executing the closure, then you would of course
> have the ability - but only if you proxy it before the closure.  To
> *me* that would feel correct.
>
> Anyway, I'm going to try to talk less I've been sending too many
> messages.  I come from Lua and I love that this functionality exists
> in Javascript exists in its own form.  I did a lot of fun things in
> Lua so this is pretty personal to me if I want to continue having fun
> in JS.
>
> I want Object.observe() to stay for tricky debug situations, but I
> think it would break information hiding/encapsulation on the web by
> allowing you to observe changes made through existing private
> references.  Proxy is what people should use, O.o() can be a private
> sexy debug tool?
>
> FIN.
> ___
> 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

Re: An update on Object.observe

[Coroutines]

On Tue, Nov 3, 2015 at 2:25 PM, Adam Klein  wrote:

> Yes, similar to nextTick() (and I agree that's better than polling,
> conceptually). But Proxies are strictly more powerful.

I agree as well - I had skipped over learning about Proxies until
someone told me about them last night.  They support trapping for a
larger number of uses - like for .. in iteration.  I had started
another thread to "Save Object.observe" after joining the mailing list
late.  I was misguided. ;>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Isiah Meadows]

Reflect.construct basically does `new Class(...args)`, but on a lower level
where you can set `new.target` in the call.

Object.observe makes it easier, but sometimes, it's useful to completely
break encapsulation from a closure. I've had a few use cases where I needed
that ability. There's been a couple times where I've explicitly yanked a
value out of a callback closure just to use it elsewhere.

And generally, Object.observe is useful for one of two things: listen for
changes as a break for encapsulation, which is what Angular 1 wanted it
for, or transfer changes to a new closure, which leads to extremely simple
POJO models in MV* architectures.

I did find a way to use it in Flux architectures as well. Here's a copy of
an email I already sent:

-

I was just thinking... Object.observe could, in theory, be used as a core
for a dispatcher and store in a Flux-like data flow. Basically, when a view
emits an event, you can use the first observed object as a memoized
dispatcher, and then it emits a list of changes that can then update
another observed object, the store. That store can then emit a list of
changes to be resolved with the views.

What do you all think?

On Wed, Nov 4, 2015, 01:17 Coroutines  wrote:

> On Tue, Nov 3, 2015 at 10:08 PM, Isiah Meadows 
> wrote:
> > Proxies can do a better, more thorough job of breaking encapsulation.
> >
> > ```js
> > var log = [];
> > String = new Proxy(String, {
> >   construct(target, newTarget, args) {
> > log.push(args);
> > return Reflect.construct(target, newTarget, args);
> >   }
> > });
> >
> > (function () {
> >   var s = String;
> >   var private = function () { return new s("cat"); }
> >   var public = function () { return private(); }
> >   return public;
> > })()
> > ```
>
> There's a possibility I am misunderstanding you but this is what I was
> trying to say is 'okay'.  If you redefined String to be a proxy before
> the closure runs then that seems "legal".
>
> I disagree with Object.observe() because you can call it after the
> closure has run and see changes made in String (or another object for
> lack of a better example) when you call the exported function.  ...but
> now I need to go read up on Reflect.  Be back in a few mins when I
> have more slightly inaccurate things to say :o)
> ___
> 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

Re: An update on Object.observe

[Brendan Eich]

> a lot of noise on this list

Agreed (re: no one in particular). :-(

Best to step back and study all of the stuff already in JS, before doubling
down on reviving another withdrawn proposal.

/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[David Bruant]

Hi,

Le 03/11/2015 12:26, Alexander Jones a écrit :
In my opinion, the fundamental record type we build our JS on should 
be getting dumber, not smarter. It feels inappropriate to be piling 
more difficult-to-reason-about mechanismson top before reeling in 
exotic host objects.
JS objects were never only the record you're talking about. They were 
also used for OOP (used as dynamic this values if one property was a 
function and called after a dot).
And DOM objects also exposed things that did not have equivalent in ES 
objects (aside from the easy "host objects" escape), so the language 
needed to catch up (as it did in ES5) despite having to be more 
difficult to reason about.


Immutable data structures might be what you're looking for though
https://github.com/sebmarkbage/ecmascript-immutable-data-structures

With Proxy out of the bag, I'm not so hopeful for the humble Object 
anymore.
This is a surprising statement. By exposing the low-level object API as 
userlang API (proxy traps + Reflect API), proxies make the low-level 
object API subject to the same backward-compat constraints as every 
other API.
If nothing else, the very existence of proxies puts an end to the 
evolution of the object model.


David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Andreas Rossberg]

On 3 November 2015 at 14:58, David Bruant  wrote:
> Le 03/11/2015 12:26, Alexander Jones a écrit :
>>
>> In my opinion, the fundamental record type we build our JS on should be
>> getting dumber, not smarter. It feels inappropriate to be piling more
>> difficult-to-reason-about mechanismson top before reeling in exotic host
>> objects.

JS objects have never been simple. Since at least ES5, which
officially added accessors, attribute reflection, and irregular
inheritance rules, the last illusion of simplicity has been eternally
lost. But before that there already were various quirks and hidden
complexities.

>> With Proxy out of the bag, I'm not so hopeful for the humble Object
>> anymore.
>
> This is a surprising statement. By exposing the low-level object API as
> userlang API (proxy traps + Reflect API), proxies make the low-level object
> API subject to the same backward-compat constraints as every other API.
> If nothing else, the very existence of proxies puts an end to the evolution
> of the object model.

There is no end to evolution. The object model will grow more
features, like private properties, which are orthogonal to proxies.

/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[lycheeJS Engine]

I think we still need Object.observe as a specification to implement proper
sandboxing of feature-detecting closures.

For example, in lycheeJS we have a sandboxing system that can inject
definitions (and their variants) at runtime, replaces them intelligently at
runtime. The definition closures have, for that purpose, all a supports()
and exports() method. Both are using a referenced object that is sandboxed.
The global property therefore is just a reference to a custom object, so
that we can trace the properties, data types and causes of the errors.

The implementation got stuck because of missing support for ES6 Proxies in
the wild, but the idea is to use them to figure out if an implementation is
doing something like window.addEventListener('asdasd') in the background
and escalating an error up to a delegation handler that figures out what to
do and what to inject to run it again. It is necessary to not only track
properties and their data type; we need a feature to track if it was a
function that threw an error or not.


Easy use case:

Imagine a var sandbox = { setTimeout: window.setTimeout }; This would throw
a context error and we would need that information with proper description
on what happened in order to isolate setTimeout and inject our In-JS
Debugger there.

We think Object.observe is an essential feature to have the simulation part
of this, because we need desperately the capabilities to have a
in-JS-written Debugger that can find such issues for our training of the
Graph NN. The execution time aspect of this is a show-stopper if it would
not be possible.


Advanced use case:

We don't use a RendererFactory that is executed once a new Renderer is
instantiated, we have multiple Renderer implementations for multiple
platforms available. Each Renderer has its own platform
(fertilizer)-specific implementation. Those implementations are called
alternative Definitions.

Each definition has a supports() method that is called once the runtime
error-determination algorithm tries to inject a new instance of the
Renderer somewhere or de-reference an old, now slowly running Renderer.

The supports() method can have all kinds of ES5 / ES6 code in order for the
determination; it is the essential point to determine the capabilities of
the runtime - at the given execution time, not compile time.

If, for example, the canvas binding in the runtime on Android has problems
now and throws some errors; there might be a fallback implementation
available (SDL / OpenGL / GLUT / whatever) and then the Environment sandbox
updates its dependencies accordingly and tries out "if one of the fallback
implementation would be supported right now".

Therefore, we think that Object.observe is quite necessary for our
live-update-and-inject algorithms to determine compatibility problems for
out-rolled updates _before_ they are applied to have proper feedback for
our NN on the other peer-side of things.


PS:

In case anyone is interested, the problem for which we would need
Object.observe and ES6 Proxies available, is here:
https://github.com/Artificial-Engineering/lycheeJS/blob/development-0.9/lychee/source/core/Environment.js#L112


But I could be totally all-wrong with this. If the described features are
possible to be implemented with ES6 Proxies alone, I'm fine with
deprecating Object.observe and with switching to ES6 Proxies. But the
features are essential for us to choose ES6/ES7 as a language and I hope
that others have similar feature requests.

~Chris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Alexander Jones]

In my opinion, the fundamental record type we build our JS on should be
getting dumber, not smarter. It feels inappropriate to be piling more
difficult-to-reason-about mechanisms on top before reeling in exotic host
objects. With Proxy out of the bag, I'm not so hopeful for the humble
Object anymore.

On Tuesday, 3 November 2015, Andrea Giammarchi 
wrote:

> Sure thing, meanwhile polymer or other libraries need to pollute getters
> and setters and the rest of the web have been trying to polyfill it for at
> least 6 years now *
>
> The reason is not widely "abused" is that it never made it as standard and
> as it is feels like an outdated spec. Proxy would give us that and much
> more, unfortunately proxies do not play so well cross environment. For
> instance, I've tried to use them in GJS ( Gtk+3 JavaScript bindings ) and
> while Object.prototype.watch always works, proxied GObjects fail to be used
> like these were just GObjects.
>
> That might be a specific env problem though, but having a way to watch
> properties, specially in two ways bindings scenarios, is a very needed
> common thing.
> As example, in DOMClass I'm replacing native getters/setters to be
> notified about changes, it doesn't feel right even if it works.
>
> All this is over-off-topic though, so I might just stop.
>
> Best Regards
>
>
>
> * just few examples since 2009
> https://gist.github.com/eligrey/384583
> https://gist.github.com/adriengibrat/b0ee333dc1b058a22b66
> question in SO
> http://stackoverflow.com/questions/1029241/javascript-object-watch-for-all-browsers
> http://deploytonenyures.blogspot.co.uk/2013/02/objectwatch-polyfill.html
>
> https://code.google.com/p/chtor/source/browse/chtor/chrome/js/object-watch.js?spec=svn2c00820d48169bb678a00447e295fb31dcf448ed=2c00820d48169bb678a00447e295fb31dcf448ed
>
> yes, I've done that too
> in 2009
> http://webreflection.blogspot.co.uk/2009/01/internet-explorer-object-watch.html
> and recently https://gist.github.com/WebReflection/366dc38574dc526308b5
>
>
>
> On Tue, Nov 3, 2015 at 2:11 AM, Boris Zbarsky  > wrote:
>
>> On 11/2/15 4:55 PM, Andrea Giammarchi wrote:
>>
>>> I agree with Benoit and I think there is a reason
>>> `Object.prototype.watch` is still in Firefox and  won't go away any time
>>> soon
>>>
>>
>> As far as I know the only reason it's there and hasn't been removed is
>> because it's used to implement debugger watchpoints [1].  And the only
>> reason it's web-exposed is because SpiderMonkey has not prioritized being
>> able to expose APIs to privileged code but not the web (something that
>> think should get fixed).
>>
>> -Boris
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=934669
>>
>> ___
>> 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

An update on Object.observe

[Adam Klein]

Over three years ago, Rafael Weinstein, Erik Arvidsson, and I set out to
design and implement what we believed to be the primitive underlying the
data-binding system of MDV ("model-driven views"). We prototyped an
implementation in a branch of V8, then got agreement from the V8 team to
build a real version upstream, while pushing Object.observe ("O.o") as a
part of the upcoming ES7 standard and working with the Polymer team to
build their data-binding system on top of O.o.

Three years later, the world has changed in a variety of ways. While other
data-binding frameworks (such as Ember and Angular) showed interest, it was
difficult to see how they could evolve their existing model to match that
of O.o. Polymer rewrote from the ground up for its 1.0 release, and in that
rebuilding did not utilize O.o. And React's processing model, which tries
to avoid the mutable state inherent in data-binding systems, has become
quite popular on the web.

After much discussion with the parties involved, I plan to withdraw the
Object.observe proposal from TC39 (where it currently sits at stage 2 in
the ES spec process), and hope to remove support from V8 by the end of the
year (the feature is used on 0.0169% of Chrome pageviews, according to
chromestatus.com).

For developers who have been experimenting with O.o and are seeking a
transition path, consider using a polyfill such as
https://github.com/MaxArt2501/object-observe or a wrapper library like
https://github.com/polymer/observe-js.

- Adam
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Benoit Marchant]

Hi Adam,

Just sharing my $0.02 : I implemented a two-way binding system in my first 
JavaScript framework at Apple in 2007, designed as a layer on top of a property 
change observing API, like in Cocoa, and that’s still our design in Montage 
today. I’ve never felt the need nor understood why observing changes on a whole 
object were useful for bindings, and without measuring, I was concerned (maybe 
wrongly) by the performance overhead of doing so.

Thanks for the update.

Benoit

> On Nov 2, 2015, at 10:27 AM, Adam Klein  wrote:
> 
> Over three years ago, Rafael Weinstein, Erik Arvidsson, and I set out to 
> design and implement what we believed to be the primitive underlying the 
> data-binding system of MDV ("model-driven views"). We prototyped an 
> implementation in a branch of V8, then got agreement from the V8 team to 
> build a real version upstream, while pushing Object.observe ("O.o") as a part 
> of the upcoming ES7 standard and working with the Polymer team to build their 
> data-binding system on top of O.o.
> 
> Three years later, the world has changed in a variety of ways. While other 
> data-binding frameworks (such as Ember and Angular) showed interest, it was 
> difficult to see how they could evolve their existing model to match that of 
> O.o. Polymer rewrote from the ground up for its 1.0 release, and in that 
> rebuilding did not utilize O.o. And React's processing model, which tries to 
> avoid the mutable state inherent in data-binding systems, has become quite 
> popular on the web.
> 
> After much discussion with the parties involved, I plan to withdraw the 
> Object.observe proposal from TC39 (where it currently sits at stage 2 in the 
> ES spec process), and hope to remove support from V8 by the end of the year 
> (the feature is used on 0.0169% of Chrome pageviews, according to 
> chromestatus.com ).
> 
> For developers who have been experimenting with O.o and are seeking a 
> transition path, consider using a polyfill such as 
> https://github.com/MaxArt2501/object-observe 
>  or a wrapper library like 
> https://github.com/polymer/observe-js .
> 
> - Adam
> ___
> 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

Re: An update on Object.observe

[Matthew Phillips]

> Over three years ago, Rafael Weinstein, Erik Arvidsson, and I set out to
> design and implement what we believed to be the primitive underlying the
> data-binding system of MDV ("model-driven views"). We prototyped an
> implementation in a branch of V8, then got agreement from the V8 team to
> build a real version upstream, while pushing Object.observe ("O.o") as a
> part of the upcoming ES7 standard and working with the Polymer team to
> build their data-binding system on top of O.o.
>
> Three years later, the world has changed in a variety of ways. While other
> data-binding frameworks (such as Ember and Angular) showed interest, it was
> difficult to see how they could evolve their existing model to match that
> of O.o. Polymer rewrote from the ground up for its 1.0 release, and in that
> rebuilding did not utilize O.o. And React's processing model, which tries
> to avoid the mutable state inherent in data-binding systems, has become
> quite popular on the web.
>
> After much discussion with the parties involved, I plan to withdraw the
> Object.observe proposal from TC39 (where it currently sits at stage 2 in
> the ES spec process), and hope to remove support from V8 by the end of the
> year (the feature is used on 0.0169% of Chrome pageviews, according to
> chromestatus.com).
>
> For developers who have been experimenting with O.o and are seeking a
> transition path, consider using a polyfill such as
> https://github.com/MaxArt2501/object-observe or a wrapper library like
> https://github.com/polymer/observe-js.
>
> - Adam
>

What is Polymer using in place of Object.observe?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Brian Chin]

Regarding the Polymer 1.0 situation, as a client the new system seems to be
simpler. The core aspect is that now when you modify a property, the
resulting changes propagate instantly. O.o required update callbacks to be
executed on a new microtask after the associated field/item was modified.
In my experience, the instant propagation is easier to reason about for the
end user.

On Mon, Nov 2, 2015 at 11:31 AM, Benoit Marchant  wrote:

> Hi Adam,
>
> Just sharing my $0.02 : I implemented a two-way binding system in my first
> JavaScript framework at Apple in 2007, designed as a layer on top of a
> property change observing API, like in Cocoa, and that’s still our design
> in Montage today. I’ve never felt the need nor understood why observing
> changes on a whole object were useful for bindings, and without measuring,
> I was concerned (maybe wrongly) by the performance overhead of doing so.
>
> Thanks for the update.
>
> Benoit
>
> On Nov 2, 2015, at 10:27 AM, Adam Klein  wrote:
>
> Over three years ago, Rafael Weinstein, Erik Arvidsson, and I set out to
> design and implement what we believed to be the primitive underlying the
> data-binding system of MDV ("model-driven views"). We prototyped an
> implementation in a branch of V8, then got agreement from the V8 team to
> build a real version upstream, while pushing Object.observe ("O.o") as a
> part of the upcoming ES7 standard and working with the Polymer team to
> build their data-binding system on top of O.o.
>
> Three years later, the world has changed in a variety of ways. While other
> data-binding frameworks (such as Ember and Angular) showed interest, it was
> difficult to see how they could evolve their existing model to match that
> of O.o. Polymer rewrote from the ground up for its 1.0 release, and in that
> rebuilding did not utilize O.o. And React's processing model, which tries
> to avoid the mutable state inherent in data-binding systems, has become
> quite popular on the web.
>
> After much discussion with the parties involved, I plan to withdraw the
> Object.observe proposal from TC39 (where it currently sits at stage 2 in
> the ES spec process), and hope to remove support from V8 by the end of the
> year (the feature is used on 0.0169% of Chrome pageviews, according to
> chromestatus.com).
>
> For developers who have been experimenting with O.o and are seeking a
> transition path, consider using a polyfill such as
> https://github.com/MaxArt2501/object-observe or a wrapper library like
> https://github.com/polymer/observe-js.
>
> - Adam
> ___
> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Benoit Marchant]

Agreed, another aspect that I never understood, and was a problem with Angular 
1.0 bindings. At least when doing it in-line, bindings don’t introduce a new 
flow compared to what a developer’s custom equivalent code would do.

Benoit

> On Nov 2, 2015, at 11:35 AM, Brian Chin  wrote:
> 
> Regarding the Polymer 1.0 situation, as a client the new system seems to be 
> simpler. The core aspect is that now when you modify a property, the 
> resulting changes propagate instantly. O.o required update callbacks to be 
> executed on a new microtask after the associated field/item was modified. In 
> my experience, the instant propagation is easier to reason about for the end 
> user.
> 
> On Mon, Nov 2, 2015 at 11:31 AM, Benoit Marchant  > wrote:
> Hi Adam,
> 
> Just sharing my $0.02 : I implemented a two-way binding system in my first 
> JavaScript framework at Apple in 2007, designed as a layer on top of a 
> property change observing API, like in Cocoa, and that’s still our design in 
> Montage today. I’ve never felt the need nor understood why observing changes 
> on a whole object were useful for bindings, and without measuring, I was 
> concerned (maybe wrongly) by the performance overhead of doing so.
> 
> Thanks for the update.
> 
> Benoit
> 
>> On Nov 2, 2015, at 10:27 AM, Adam Klein > > wrote:
>> 
>> Over three years ago, Rafael Weinstein, Erik Arvidsson, and I set out to 
>> design and implement what we believed to be the primitive underlying the 
>> data-binding system of MDV ("model-driven views"). We prototyped an 
>> implementation in a branch of V8, then got agreement from the V8 team to 
>> build a real version upstream, while pushing Object.observe ("O.o") as a 
>> part of the upcoming ES7 standard and working with the Polymer team to build 
>> their data-binding system on top of O.o.
>> 
>> Three years later, the world has changed in a variety of ways. While other 
>> data-binding frameworks (such as Ember and Angular) showed interest, it was 
>> difficult to see how they could evolve their existing model to match that of 
>> O.o. Polymer rewrote from the ground up for its 1.0 release, and in that 
>> rebuilding did not utilize O.o. And React's processing model, which tries to 
>> avoid the mutable state inherent in data-binding systems, has become quite 
>> popular on the web.
>> 
>> After much discussion with the parties involved, I plan to withdraw the 
>> Object.observe proposal from TC39 (where it currently sits at stage 2 in the 
>> ES spec process), and hope to remove support from V8 by the end of the year 
>> (the feature is used on 0.0169% of Chrome pageviews, according to 
>> chromestatus.com ).
>> 
>> For developers who have been experimenting with O.o and are seeking a 
>> transition path, consider using a polyfill such as 
>> https://github.com/MaxArt2501/object-observe 
>>  or a wrapper library like 
>> https://github.com/polymer/observe-js 
>> .
>> 
>> - Adam
>> ___
>> 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 
> 
> 
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Adam Klein]

On Mon, Nov 2, 2015 at 11:21 AM, Matthew Phillips 
wrote:

>
> Over three years ago, Rafael Weinstein, Erik Arvidsson, and I set out to
>> design and implement what we believed to be the primitive underlying the
>> data-binding system of MDV ("model-driven views"). We prototyped an
>> implementation in a branch of V8, then got agreement from the V8 team to
>> build a real version upstream, while pushing Object.observe ("O.o") as a
>> part of the upcoming ES7 standard and working with the Polymer team to
>> build their data-binding system on top of O.o.
>>
>> Three years later, the world has changed in a variety of ways. While
>> other data-binding frameworks (such as Ember and Angular) showed interest,
>> it was difficult to see how they could evolve their existing model to match
>> that of O.o. Polymer rewrote from the ground up for its 1.0 release, and in
>> that rebuilding did not utilize O.o. And React's processing model, which
>> tries to avoid the mutable state inherent in data-binding systems, has
>> become quite popular on the web.
>>
>> After much discussion with the parties involved, I plan to withdraw the
>> Object.observe proposal from TC39 (where it currently sits at stage 2 in
>> the ES spec process), and hope to remove support from V8 by the end of the
>> year (the feature is used on 0.0169% of Chrome pageviews, according to
>> chromestatus.com).
>>
>> For developers who have been experimenting with O.o and are seeking a
>> transition path, consider using a polyfill such as
>> https://github.com/MaxArt2501/object-observe or a wrapper library like
>> https://github.com/polymer/observe-js.
>>
>> - Adam
>>
>
> What is Polymer using in place of Object.observe?
>

Polymer uses a mix of getters/setters and DOM events to handle data
propagation. Details can be found on polymer-project.org, e.g.:

https://www.polymer-project.org/1.0/docs/devguide/properties.html#change-callbacks
https://www.polymer-project.org/1.0/docs/devguide/data-binding.html#change-notification-protocol
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Andrea Giammarchi]

I agree with Benoit and I think there is a reason `Object.prototype.watch`
is still in Firefox and  won't go away any time soon, as well as I think
there is a reason  everyone would like to play with Proxies instead, but
regardless in  ES2015 these are still basically nowhere.

Debouncing some change can be done quite easily and intercepting and/or
handling changes are at the end what devs are interested on so I personally
+1 this decision.

I wish `Object#watch` made it further long time ago :-)

Best Regards

On Mon, Nov 2, 2015 at 7:31 PM, Benoit Marchant  wrote:

> Hi Adam,
>
> Just sharing my $0.02 : I implemented a two-way binding system in my first
> JavaScript framework at Apple in 2007, designed as a layer on top of a
> property change observing API, like in Cocoa, and that’s still our design
> in Montage today. I’ve never felt the need nor understood why observing
> changes on a whole object were useful for bindings, and without measuring,
> I was concerned (maybe wrongly) by the performance overhead of doing so.
>
> Thanks for the update.
>
> Benoit
>
> On Nov 2, 2015, at 10:27 AM, Adam Klein  wrote:
>
> Over three years ago, Rafael Weinstein, Erik Arvidsson, and I set out to
> design and implement what we believed to be the primitive underlying the
> data-binding system of MDV ("model-driven views"). We prototyped an
> implementation in a branch of V8, then got agreement from the V8 team to
> build a real version upstream, while pushing Object.observe ("O.o") as a
> part of the upcoming ES7 standard and working with the Polymer team to
> build their data-binding system on top of O.o.
>
> Three years later, the world has changed in a variety of ways. While other
> data-binding frameworks (such as Ember and Angular) showed interest, it was
> difficult to see how they could evolve their existing model to match that
> of O.o. Polymer rewrote from the ground up for its 1.0 release, and in that
> rebuilding did not utilize O.o. And React's processing model, which tries
> to avoid the mutable state inherent in data-binding systems, has become
> quite popular on the web.
>
> After much discussion with the parties involved, I plan to withdraw the
> Object.observe proposal from TC39 (where it currently sits at stage 2 in
> the ES spec process), and hope to remove support from V8 by the end of the
> year (the feature is used on 0.0169% of Chrome pageviews, according to
> chromestatus.com).
>
> For developers who have been experimenting with O.o and are seeking a
> transition path, consider using a polyfill such as
> https://github.com/MaxArt2501/object-observe or a wrapper library like
> https://github.com/polymer/observe-js.
>
> - Adam
> ___
> 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
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: An update on Object.observe

[Fish Rock]

To be clear, I'm neither for nor against this (I do not fully know the 
use-cases or caveats of Object.observe). However, short timelines are an easy 
way to cause deep pain in the node ecosystem.

~Jeremiah
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: An update on Object.observe

[Boris Zbarsky]

On 11/2/15 4:55 PM, Andrea Giammarchi wrote:

I agree with Benoit and I think there is a reason
`Object.prototype.watch` is still in Firefox and  won't go away any time
soon


As far as I know the only reason it's there and hasn't been removed is 
because it's used to implement debugger watchpoints [1].  And the only 
reason it's web-exposed is because SpiderMonkey has not prioritized 
being able to expose APIs to privileged code but not the web (something 
that think should get fixed).


-Boris

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=934669
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss