The only reason I've used `__noSuchProperty__` name in that example was to
indeed remind `__noSuchMethod__` and others anti-name-clashing old patterns
we all know but basically I was trying to explain that composing instead of
extending is a win for these kind of magic behaviors.
It is possible
Tab Atkins Jr. wrote:
I don't understand how you inferred from Andrea's post that this
wish-fulfillment __noSuchProperty__ magic property does not have to
handle superclass delegation..
I did not infer that from Andrea's post as his position -- rather the
reverse, because he said I also think
On Fri, Sep 26, 2014 at 10:29 AM, Brendan Eich bren...@mozilla.org wrote:
Tab Atkins Jr. wrote:
I don't understand how you inferred from Andrea's post that this
wish-fulfillment __noSuchProperty__ magic property does not have to
handle superclass delegation..
I did not infer that from
Dean Landolt wrote:
Out of curiosity, wouldn't Object.observe require implementors to add
precisely this kind of hook into the vm anyway?
No, but O.o has its own costs. See
http://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/0204.html
/be
On Fri, Sep 26, 2014 at 5:01 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
On Thu, Sep 25, 2014 at 6:56 PM, Boris Zbarsky bzbar...@mit.edu wrote:
SpiderMonkey used to support __noSuchMethod__, I believe.
It's still there.
js var anObject = { __noSuchMethod__() { return what; } };
js
Brendan Eich wrote:
Dean Landolt wrote:
Out of curiosity, wouldn't Object.observe require implementors to add
precisely this kind of hook into the vm anyway?
No, but O.o has its own costs. See
http://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/0204.html
To say a bit more,
Dean Landolt wrote:
http://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/0204.html
Sure, O.o isn't free, and I get that using @noSuchProperty would
likely result in all kinds of deoptimization. But of all the costs
listed in that thread, I'm not seeing any mention of the
Brendan Eich wrote:
A general-purpose (as its name implies) nSP would hit lookup (get as
well as set) paths, not just mutation (set). But it seems Andreas's
just to clear up some myths words were missed, even considering only
mutation (not notification).
From private correspondence with
On Thu, Sep 25, 2014 at 5:38 PM, Brendan Eich bren...@mozilla.org wrote:
On Sep 25, 2014, at 7:56 PM, Boris Zbarsky bzbar...@mit.edu wrote:
SpiderMonkey used to support __noSuchMethod__, I believe.
I implemented __noSuchMethod__ long ago, for the TIBET folks (Smalltalk style
JS framework;
Tab Atkins Jr. wrote:
Any nSP of the kind we seem to be discussing would need to fail fast, on
evaluation of the dot expression. That is a fast path.
I, personally, have only ever used Python and PHP's nSP functionality
to implement methods. Most of the fancy uses I see for it in, say,
Ruby
On Wed, Sep 24, 2014 at 3:28 PM, Brendan Eich bren...@mozilla.org wrote:
Tab Atkins Jr. wrote:
Using subclassing to bung in some arbitrary trait is really terrible.
:/ It requires either adding it up high in your class hierarchy, or
having to write a custom NoSuchPropertyClass which extends
On Thu, Sep 25, 2014 at 12:50 PM, Brendan Eich bren...@mozilla.org wrote:
Tab Atkins Jr. wrote:
If you try to add it in a targeted way in the middle of
your hierarchy, it requires either __proto__ hacking, something like:
class superclass {...}
...
x = makeNSPProxy()
x.__proto__ =
On 9/25/14, 4:31 PM, Tab Atkins Jr. wrote:
Yes, that is what I'm proposing. If lookup fails completely (reaches
Object.prototype without finding the named property), it then does a
second lookup for the magic NSP property, and if it finds it, executes
it with the property name, returning the
On Sep 25, 2014, at 7:56 PM, Boris Zbarsky bzbar...@mit.edu wrote:
SpiderMonkey used to support __noSuchMethod__, I believe.
I implemented __noSuchMethod__ long ago, for the TIBET folks (Smalltalk style
JS framework; they wanted a doesNotUnderstand analogue).
Please note well the difference
Brendan Eich wrote:
Tab Atkins Jr. wrote:
This works great as a general principle, but honestly tons of
languages have already forged this path. It's pretty straightforward,
I think.
I made the case for building it in sooner, but TC39 wanted less
sooner based on library usage. There was a
On Wed, Sep 24, 2014 at 2:56 PM, Brendan Eich bren...@mozilla.org wrote:
Brendan Eich wrote:
Tab Atkins Jr. wrote:
This works great as a general principle, but honestly tons of
languages have already forged this path. It's pretty straightforward,
I think.
I made the case for building it
Agreed with Tab, in terms of composing inherited functionality it's hard to
beat prototypal and the ease of `Class.prototype.__noSuchProperty__ =
function(){ ... };` traitish approach.
I also think Proxy already gives us a way to work around the
`__noSuchProperty__` issue
On Wed, Sep 24, 2014 at
Tab Atkins Jr. wrote:
Using subclassing to bung in some arbitrary trait is really terrible.
:/ It requires either adding it up high in your class hierarchy, or
having to write a custom NoSuchPropertyClass which extends your
superclass, so you can then extend it.
Ok, let's not hand-wave mixin
Hi Nicholas, sorry for the tardy reply. I did propose NoSuchProperty to
Ecma TC39 today. To recap:
// Library code starts here.
const NoSuchProperty = Proxy(Object.prototype, {
// uncomment for nasty Firefox bug workaround:
// has: function(target, name) { return true; },
get:
On Tue, Sep 23, 2014 at 2:34 PM, Brendan Eich bren...@mozilla.org wrote:
Hi Nicholas, sorry for the tardy reply. I did propose NoSuchProperty to Ecma
TC39 today. To recap:
// Library code starts here.
const NoSuchProperty = Proxy(Object.prototype, {
// uncomment for nasty Firefox bug
Tab Atkins Jr. wrote:
This works great as a general principle, but honestly tons of
languages have already forged this path. It's pretty straightforward,
I think.
I made the case for building it in sooner, but TC39 wanted less sooner
based on library usage. There was a minority position (as
Andrea Giammarchi wrote:
In such case the only concern would be why `Object.prototype` is
considered but not inherited properties too.
Because NoSuchProperty is meant to be inserted just before
Object.prototype, avoiding that loop.
What's more, the loop is unnecessary:
var NoSuchProperty =
Because NoSuchProperty is meant to be inserted just before
Object.prototype
I miss this constrain, wouldn't have bothered with the loop otherwise.
Regards
On Sun, Jun 15, 2014 at 11:27 AM, Brendan Eich bren...@mozilla.org wrote:
Andrea Giammarchi wrote:
In such case the only concern would
that `has:()=true` breaks with features detections that are meant to be
less obtrusive than getters ... i.e. `'geolocation' in navigator` or
`'innerHTML' in genericNode` and all others that are not supposed to pass
through a potentially expensive getter to retrieve a feature detection
purpose
Interesting bug, thanks for the info.
In such case the only concern would be why `Object.prototype` is considered
but not inherited properties too.
If inheritance should be considered, I'd rather go like this:
```
var NoSuchProperty = Proxy({}, {
get: function(target, name, receiver) {
Le 06/06/2014 01:08, Rick Waldron a écrit :
On Thu, Jun 5, 2014 at 6:42 PM, Nicholas C. Zakas
standa...@nczconsulting.com mailto:standa...@nczconsulting.com wrote:
* `Object.deepPreventExtensions()`, `Object.deepSeal()`,
`Object.deepFreeze()` - deep versions of
On Fri, Jun 6, 2014 at 5:44 AM, David Bruant bruan...@gmail.com wrote:
Le 06/06/2014 01:08, Rick Waldron a écrit :
On Thu, Jun 5, 2014 at 6:42 PM, Nicholas C. Zakas
standa...@nczconsulting.com wrote:
* `Object.deepPreventExtensions()`, `Object.deepSeal()`,
`Object.deepFreeze()` - deep
Le 06/06/2014 15:57, Mark S. Miller a écrit :
By contrast, a Map's state is more like the private instance variable
state of a closure or a post-ES6 class.
The capabilities to arbitrarily modify Maps (set/delete on all keys,
with any values) will be expected by any ES6-compliant code to be
On Fri, Jun 6, 2014 at 7:37 AM, David Bruant bruan...@gmail.com wrote:
Le 06/06/2014 15:57, Mark S. Miller a écrit :
By contrast, a Map's state is more like the private instance variable
state of a closure or a post-ES6 class.
The capabilities to arbitrarily modify Maps (set/delete on all
Couldn't preventUndeclaredGet() be implemented with proxies?
It actually sounds like an extremely useful feature for development builds
of libraries and applications. Typos are very very common, and often
difficult to look over while debugging. On the other hand, it would break
a lot of
Le 06/06/2014 17:47, Frankie Bagnardi a écrit :
Couldn't preventUndeclaredGet() be implemented with proxies?
Yes it can. Doing it left as an exercise to the reader... Wait... Don't
bother, Nicholas did it :-)
http://www.nczonline.net/blog/2014/04/22/creating-defensive-objects-with-es6-proxies/
On 6/5/2014 4:08 PM, Rick Waldron wrote:
* `Object.deepPreventExtensions()`, `Object.deepSeal()`,
`Object.deepFreeze()` - deep versions of
`Object.preventExtensions()`, et al.
Does deep mean that a Map instance's [[MapData]] is frozen if
deepFreeze is called on a ? eg. what
On 6/6/2014 8:38 AM, Mark S. Miller wrote:
But the concern Nicholas raises doesn't seem to have this
property. Reading a property that doesn't exist doesn't carry a
security risk, does it? Object.preventUndeclaredGet doesn't really
protect against anything like ES5 methods did.
Le 06/06/2014 18:16, Nicholas C. Zakas a écrit :
On 6/6/2014 8:38 AM, Mark S. Miller wrote:
But the concern Nicholas raises doesn't seem to have this
property. Reading a property that doesn't exist doesn't carry a
security risk, does it? Object.preventUndeclaredGet doesn't
On Fri, Jun 6, 2014 at 8:38 AM, Mark S. Miller erig...@google.com wrote:
The most common way to do such feature testing is to get the property and
see if it is falsy.
this is why for years many of us have been advocating the usage of `'name'
in object` instead of passing through getters ...
Nicholas C. Zakas wrote:
It can be done with Proxy, but that kind of sucks because I always
need to go through the extra step of creating the Proxy for each
object and passing around the Proxy instead. To me, this is similar to
setting a property to be readonly in strict mode, except its
Just FTR, I'll put a ratioanlized ES7 proposal on the agenda for the
July TC39 meeting, as per
https://twitter.com/BrendanEich/status/475067783282057216
Thanks to Nicholas for the suggestion!
/be
Brendan Eich wrote:
Nicholas C. Zakas wrote:
It can be done with Proxy, but that kind of sucks
that `has:()=true` breaks with features detections that are meant to be
less obtrusive than getters ... i.e. `'geolocation' in navigator` or
`'innerHTML' in genericNode` and all others that are not supposed to pass
through a potentially expensive getter to retrieve a feature detection
purpose
I wrote this blog post about some of the pain points I'm dealing with
and dreams of how ES7 might be able to address them:
http://www.nczonline.net/blog/2014/06/03/my-ecmascript-7-wishlist/
A short overview in lieu of posting the whole article here:
* `Array.prototype.first
On Thu, Jun 5, 2014 at 6:42 PM, Nicholas C. Zakas
standa...@nczconsulting.com wrote:
I wrote this blog post about some of the pain points I'm dealing with and
dreams of how ES7 might be able to address them:
http://www.nczonline.net/blog/2014/06/03/my-ecmascript-7-wishlist/
A short
* `Function.empty` - a standard empty function that can be used when you just
want an empty function (IMHO, it indicates intent much better than other
options toda).
Ironically, that’s what Function.prototype is. But using that object in that
capacity is beyond confusing. I’d prefer a
Rick Waldron wrote:
* `Object.preventUndeclaredGet()` - change an object's behavior to
throw an error if you try to read from a property that doesn't
exist (instead of returning `undefine`).
This can be achieved with Proxy right, or is that too cumbersome?
js var NoSuchProperty
On Jun 5, 2014, at 5:52 PM, Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
* `Object.preventUndeclaredGet()` - change an object's behavior to throw an
error if you try to read from a property that doesn't exist (instead of
returning `undefine`).
This can be achieved with
LOL - as if O.p has getters!
Thanks, this is more general in case of insanity.
/be
On Jun 5, 2014, at 6:09 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jun 5, 2014, at 5:52 PM, Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
* `Object.preventUndeclaredGet()` -
On Jun 5, 2014, at 6:25 PM, Brendan Eich bren...@mozilla.org wrote:
LOL - as if O.p has getters!
Thanks, this is more general in case of insanity.
It probably always a good idea to use Reflect.* calls inside of proxy handlers.
I’m seen variants of this mistake in many handlers snippets
45 matches
Mail list logo
