I would say it is most definitely not the concern of Observe to watch reads
and between accessors and Proxies we have all the tools we need for that.
With the ability to keep present on notifications of changes via observe
it's actually possible to implement a mirror that can be emit change events
On Thu, Aug 23, 2012 at 7:06 AM, Brandon Benvie
bran...@brandonbenvie.comwrote:
I would say it is most definitely not the concern of Observe to watch
reads and between accessors and Proxies we have all the tools we need for
that.
I think that misreads the situation. Having proxies available
On Wednesday, August 22, 2012 at 6:34 AM, Steve Sanderson wrote:
This is fantastic - thanks for pushing this forwards, Rafael!
For context, I'm part of the knockout.js (a JavaScript MV* library) team, so
I have some interest in how this could work out. This spec has a lot of
potential
Hi Steve,
Thanks for joining the conversation. =-)
The automatic dependency discovery that Knockout does is rather cool.
My sense has been that Proxy is a better tool for this job than is
expanding the semantics of Object.observe() to include reads.
Object.observe() only operates on objects
On Sun, Aug 19, 2012 at 3:31 PM, Rafael Weinstein rafa...@chromium.orgwrote:
On Sun, Aug 19, 2012 at 11:25 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Fri, Aug 17, 2012 at 9:49 PM, Rafael Weinstein rafa...@chromium.org
wrote:
A synchronous observation mechanism provides
The Object owner is a bit inconsistent concept in JS + DOM world.
document.body.innerHTML = 'diva hraf=#link/a/div';
is a very basic example ...
1. was the user owning the document.body ? I don't think so, body is
created in any case even if not specified in the markup
2. was the user
Le 19/08/2012 09:40, Andrea Giammarchi a écrit :
The Object owner is a bit inconsistent concept in JS + DOM world.
No and yes, but no when one is careful.
The piece of code that creates an object can be considered as its owner.
If some code accesses an object only if it's given a reference to
but then, as you write, if I decide to expose an object or I can reach an
object and then use Object.observe there is no ownership problem since
whoever let me reach that object didn't want to block me doing so ... also
because the Object.freeze(exposedObject) is an easy solution where
internally,
The core improvement for Object.observe() here is that instead of
delivering *nested* changes, unrolling of observers happens one after the
other. The design of the system never puts observers on the stack on top of
each other, meaning that whatever happens as a result of code you happen to
call
On Sun, Aug 19, 2012 at 11:25 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Fri, Aug 17, 2012 at 9:49 PM, Rafael Weinstein rafa...@chromium.org
wrote:
A synchronous observation mechanism provides an attacker too many
opportunities for a plan interference attack. If you'll
Rafael Weinstein wrote:
On Fri, Aug 17, 2012 at 8:03 PM, Brendan Eichbren...@mozilla.org wrote:
Mark S. Miller wrote:
On Fri, Aug 17, 2012 at 6:49 PM, Brendan Eichbren...@mozilla.org
mailto:bren...@mozilla.org wrote:
All praise to Raf et al., my concern is that something
On Sat, Aug 18, 2012 at 3:06 PM, Brendan Eich bren...@mozilla.org wrote:
Rafael Weinstein wrote:
On Fri, Aug 17, 2012 at 8:03 PM, Brendan Eichbren...@mozilla.org wrote:
Mark S. Miller wrote:
On Fri, Aug 17, 2012 at 6:49 PM, Brendan Eichbren...@mozilla.org
mailto:bren...@mozilla.org
I wish this is landing in Canary ASAP, I understand everything is doable
through Proxy but:
1. Proxy is nowhere, Proxy is more complicated
2. Proxy means dealing with objects wrappers and wrappers owners,
Object.observe deals with the object everyone is using, not its own wrap
3.
Hi Rafael
Would this proposal work on the Object prototype? If so then it could be
used for JSON hijacking. I'd recommend it didn't.
Cheers
Gareth
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
the Notifier is lazily instantiated and I believe not enumerable so
JSON.stringify should ever expose this property.
Moreover, it does not look like there is a {}.__notifier__ property
anywhere, Object.getNotifier(obj) is required indeed so a WeakMap that
relates the obj, and its notifier, cannot
typo: should *never* expose the not enumerable property
On Fri, Aug 17, 2012 at 10:57 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
the Notifier is lazily instantiated and I believe not enumerable so
JSON.stringify should ever expose this property.
Moreover, it does not look like
On 17 August 2012 10:57, Andrea Giammarchi andrea.giammar...@gmail.comwrote:
the Notifier is lazily instantiated and I believe not enumerable so
JSON.stringify should ever expose this property.
Moreover, it does not look like there is a {}.__notifier__ property
anywhere,
Yes, only own properties are taken into account.
I think there might be some open issues related to __proto__ depending on
whether it ends up being an accessor or magic data property in the end.
On Aug 17, 2012 6:04 AM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
As far as I can tell,
Hi gaz,
Thanks so much for your time.
Much care has been taking with this proposal to ensure that it is
neutral with respect to the existing JS Object/Security model.
As I understand it, the core vulnerability with JSON hacking is the
ability to define getters on the Object prototype.
You can observe the Object.prototype same you can define setters and stuff
there ... observing it won't affect literals or new object creation since
it works with own properties.
On Fri, Aug 17, 2012 at 2:46 PM, gaz Heyes gazhe...@gmail.com wrote:
On 17 August 2012 14:31, Andrea Giammarchi
I agree on the above with regard to Proxies. They are awesome and allow for
incredible things, but Object.observe fills a different use case that I
think is more common at at the user standpoint or at least library
standpoint. When you look around at the major JS libraries that exist the
problem
All praise to Raf et al., my concern is that something synchronous, plus
event loop concurrency and setImmediate, would suffice to bootstrap the
rather more elaborate proposal on top of the simpler O.p.watch like
fundament.
This is not to say we shouldn't standardize higher-level APIs, and
On Fri, Aug 17, 2012 at 6:49 PM, Brendan Eich bren...@mozilla.org wrote:
All praise to Raf et al., my concern is that something synchronous, plus
event loop concurrency and setImmediate, would suffice to bootstrap the
rather more elaborate proposal on top of the simpler O.p.watch like
Tab Atkins Jr. wrote:
On Fri, Aug 17, 2012 at 6:49 PM, Brendan Eichbren...@mozilla.org wrote:
All praise to Raf et al., my concern is that something synchronous, plus
event loop concurrency and setImmediate, would suffice to bootstrap the
rather more elaborate proposal on top of the simpler
On Fri, Aug 17, 2012 at 6:49 PM, Brendan Eich bren...@mozilla.org wrote:
All praise to Raf et al., my concern is that something synchronous, plus
event loop concurrency and setImmediate, would suffice to bootstrap the
rather more elaborate proposal on top of the simpler O.p.watch like
On Fri, Aug 17, 2012 at 8:03 PM, Brendan Eich bren...@mozilla.org wrote:
Mark S. Miller wrote:
On Fri, Aug 17, 2012 at 6:49 PM, Brendan Eich bren...@mozilla.org
mailto:bren...@mozilla.org wrote:
All praise to Raf et al., my concern is that something
synchronous, plus event loop
On Fri, Aug 17, 2012 at 7:30 PM, Brendan Eich bren...@mozilla.org wrote:
and they're *very*
prone to making the browser crashy. Get the slightest thing wrong in
your implementation, and suddenly the user is holding onto a null
pointer.
This you'll have to explain more. What pointer, to
I've created a bunch of cool demos and a video which attempts to
explain the use cases need for Object.observe().
https://plus.google.com/u/1/111386188573471152118
On Mon, Aug 13, 2012 at 12:28 PM, Rafael Weinstein rafa...@chromium.org wrote:
Hi all,
As promised, here is an experimental
I love it.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
just seen it, looks like an improved alternative to the good old, non
standard, Object.prototype.watch ... but
1. records are not struct like, properties might be or might not be
there rather than being there with undefined values ... is this heading to
not optimal performances in V8 and
On Tue, Aug 14, 2012 at 10:33 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
just seen it, looks like an improved alternative to the good old, non
standard, Object.prototype.watch
Key differences include:
* unlike watch(), you can be informed not only of deletions but also
if fixed-ish shape is not a performance issue then is fine, still I would
put in this fixed-ish shape a currentValue property, not only the oldValue
one, to avoid constantly and repeated checks to record.object[record.name]
If not holded, GC has to take care of them in any case, isn't it?
I know
On Tue, Aug 14, 2012 at 5:31 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
if fixed-ish shape is not a performance issue then is fine, still I would
put in this fixed-ish shape a currentValue property, not only the oldValue
one, to avoid constantly and repeated checks to
so write on specs that record.object[record.name] won't point to the actual
value ... and let's see the outcome ( I mean ... sorry, what? )
if oldValue is granted, currentValue should be granted as well I guess, at
least per each notification stack. How come this is not the case?
On Tue, Aug 14,
Hi all,
As promised, here is an experimental implementation of the
Object.observe strawman in a branch of v8:
https://github.com/rafaelw/v8
[Note that there are Mac Windows binaries of Chromium for everyone's
convenience. The links to the binaries are contained in the README.md
-- and also at
35 matches
Mail list logo
