That should have been @@isValue (Set/Map) and @@isKey (Map.

The downside of having an @@isValue filter is that there are likely still ways to get around it (subclasses could define their own, create a new object whose [[Prototype]] is an instance of your subclass with its own @@isValue, etc.). Too bad there's no way to *really* seal a member.

The options argument could be a definitive solution, though. The Set constructor could use the provided options to set an internal slot for a value filter. There's possibly still a hole that can't be closed due to constructor/prototype tricks.

Ton

Sent from my Windows Phone
________________________________
From: Ron Buckton<mailto:rbuckton at chronicles.org>
Sent: ‎8/‎11/‎2014 6:45 PM
To: Tab Atkins Jr.<mailto:jackalmage at gmail.com>; Allen Wirfs-Brock<mailto:allen at wirfs-brock.com>
Cc: Brendan Eich<mailto:brendan at mozilla.com>; es-discuss<mailto:es-discuss at mozilla.org>
Subject: RE: Overriding Map/etc with get/set hooks?

Sorry for the short reply here, as I'm not at my PC.

Would having an @@isValue (Map) and @@isKey (Set/Map) work?

Set.prototype[@@isValue] = value => true; // default

Built -in Set operations would check values against @@isValue and throw. You can then override it in your subclass and make it non-configurable.

Alternatively, there could be an options argument on the Set constructor where you could supply a value filter.

Ron
Sent from my Windows Phone
________________________________
From: Tab Atkins Jr.<mailto:jackalmage at gmail.com>
Sent: ‎8/‎11/‎2014 5:55 PM
To: Allen Wirfs-Brock<mailto:allen at wirfs-brock.com>
Cc: Brendan Eich<mailto:brendan at mozilla.com>; es-discuss<mailto:es-discuss at mozilla.org>
Subject: Re: Overriding Map/etc with get/set hooks?

Restarting this thread, because it's still an issue a year+ on.

In the Font Loading spec <http://dev.w3.org/csswg/css-font-loading/>,
I have a FontFaceSet interface
<http://dev.w3.org/csswg/css-font-loading/#FontFaceSet-interface>,
which is a Set that contains FontFace objects, plus a few other
methods and attributes.

Except that it's not a Set, because I can't subclass Sets reliably.
Instead, I have to duplicate the entire Set interface *as it exists
today*, and have it delegate to a hidden internal Set object.  This
means that when TC39 extends the Set interface, FontFaceSet will have
to be manually updated and bugfixed to contain its own version of the
new methods.  It also means that when authors define new methods on
Set.prototype, they don't apply to FontFaceSet objects unless they
manually copy them to FontFaceSet.prototype as well.

This is obviously bad.  But I can't just directly subclass Set.  If I
do, then authors can do Set.prototype.add(ffset, "hahaha, I'm a
string, not a font face!"), and then the Set is corrupted.  I could,
of course, defensively write all the FFS operations to check each
entry for being a FontFace object first, but that's not quite enough,
because *authors* also have to do this when iterating a FFS.

It's accepted and idiomatic for all sorts of methods in the web
platform to do typechecks on their arguments, and throw errors when
they don't match what's expected.  It's impossible for me to robustly
do this for the Set and Map methods, though.  Can we come up with
something that allows me to enforce these kinds of checks, like I'm
currently doing with my Set-lookalike, and like we do everywhere else
in the entire web platform?

~TJ
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140812/a146c1f5/attachment.html>

That should have been @@isValue (Set/Map) and @@isKey (Map.

The downside of having an @@isValue filter is that there are likely still ways to get around it (subclasses could define their own, create a new object whose [[Prototype]] is an instance of your subclass with its own @@isValue, etc.). Too bad there's no way to *really* seal a member.

The options argument could be a definitive solution, though. The Set constructor could use the provided options to set an internal slot for a value filter. There's possibly still a hole that can't be closed due to constructor/prototype tricks.