When a property is added to an object using a private symbol, it creates a
new kind of slot: a private slot. It is clear from the design of the
Proxy API that this represents a fundamentally new extension to the ES
object model.
On the very first paragraph of the CoffeeScript homepage, we read:
On Mon, Jan 14, 2013 at 10:57 AM, Kevin Smith khs4...@gmail.com wrote:
When a property is added to an object using a private symbol, it creates a
new kind of slot: a private slot. It is clear from the design of the Proxy
API that this represents a fundamentally new extension to the ES object
On Jan 14, 2013, at 8:04 AM, Sam Tobin-Hochstadt wrote:
On Mon, Jan 14, 2013 at 10:57 AM, Kevin Smith khs4...@gmail.com wrote:
When a property is added to an object using a private symbol, it creates a
new kind of slot: a private slot. It is clear from the design of the Proxy
API that this
I (as one of the people who has advocated for symbols) disagree
entirely. The JS object model extension required for symbols is small
-- JS objects now map from either strings or symbols to values (plus
prototype inheritance, getters, setters, configurability,
writeability, and the other
On Mon, Jan 14, 2013 at 11:28 AM, Kevin Smith khs4...@gmail.com wrote:
I (as one of the people who has advocated for symbols) disagree
entirely. The JS object model extension required for symbols is small
-- JS objects now map from either strings or symbols to values (plus
prototype
As further evidence, the word private does not even occur in sections
8.1.6 and 8.1.6.1 of the current ES6 draft. These are the sections that
define the ES6 object model. Small changes and additions had to be made
to allow for property keys to be either strings or symbols but those
changes
Le 14/01/2013 16:57, Kevin Smith a écrit :
When a property is added to an object using a private symbol, it
creates a new kind of slot: a private slot. It is clear from the
design of the Proxy API that this represents a fundamentally new
extension to the ES object model.
On the very first
There is no new kind of slot. Symbols, private and otherwise, go in
exactly the same kind of slot as any other object property.
Slots keyed with private symbols have different, novel behavior. Behavior
that did not exist before. At the very least, these slots are:
1) Strongly
Unless I missed a beat, they are not unfreezable. They are exactly like
normal properties except they are not enumerated by any existing
method including gOPN.
On Monday, January 14, 2013, Kevin Smith wrote:
There is no new kind of slot. Symbols, private and otherwise, go in
exactly the same
No boilerplate, no additional runtime costs than what's necessary.
Arguably, all of those examples could be addressed by unique symbols.
Where is the need for strong runtime enforcement of encapsulation?
I would personally like to see answers to the following questions:
- Do private
On Jan 14, 2013, at 8:38 AM, Kevin Smith wrote:
There is no new kind of slot. Symbols, private and otherwise, go in
exactly the same kind of slot as any other object property.
Slots keyed with private symbols have different, novel behavior. Behavior
that did not exist before. At the
On Mon, Jan 14, 2013 at 11:50 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jan 14, 2013, at 8:38 AM, Kevin Smith wrote:
There is no new kind of slot. Symbols, private and otherwise, go in
exactly the same kind of slot as any other object property.
Slots keyed with private
And again, `Object.freeze` can be thought of as simply enumerating the
accessible properties and freezes them, which works unchanged with
private symbols, since they are not reflectively accessible via
getOwnPropertyNames.
I think of this fact as rather supporting my view, because freezing
On Mon, Jan 14, 2013 at 12:47 PM, Kevin Smith khs4...@gmail.com wrote:
And again, `Object.freeze` can be thought of as simply enumerating the
accessible properties and freezes them, which works unchanged with
private symbols, since they are not reflectively accessible via
getOwnPropertyNames.
From the teachability perspective, I'm tired of explaining the closure
hack to explain private properties. Even to some who are experienced
webdevs, I have to explain that they can't access the private property
through this..
The language needs to evolve to the point where people can write
The concept of freezing the whole object is the problem. If you
call `freeze` on a DOM object, does the page stop changing? Of course
not -- objects can have hidden state that you, the client of that
object, have no access to and thus no way to freeze. This isn't
something new being added
Le 14 janv. 2013 à 19:29, Kevin Smith khs4...@gmail.com a écrit :
The concept of freezing the whole object is the problem. If you
call `freeze` on a DOM object, does the page stop changing? Of course
not -- objects can have hidden state that you, the client of that
object, have no
—Claude
Le 14 janv. 2013 à 20:46, Claude Pache claude.pa...@gmail.com a écrit :
Le 14 janv. 2013 à 19:29, Kevin Smith khs4...@gmail.com a écrit :
The concept of freezing the whole object is the problem. If you
call `freeze` on a DOM object, does the page stop changing? Of course
On Mon, Jan 14, 2013 at 5:46 PM, Mark S. Miller erig...@google.com wrote:
At
http://code.google.com/p/es-lab/downloads/detail?name=distr-erights-in-js.pdf
Paper for invited talk at ESOP2013 http://www.etaps.org/2013/esop13
Final already submitted, but comments of course appreciated anyway.
A fair point. By contracts in that first word, we refer to
real-world contracts. For software contracts, we initially had a
footnote trying to explain the relationship between the smart
contracts we're talking about and the type-like contracts that this
literature refers to. Perhaps unwisely, I
On Mon, Jan 14, 2013 at 3:05 PM, Mark S. Miller erig...@google.com wrote:
A fair point. By contracts in that first word, we refer to
real-world contracts. For software contracts, we initially had a
footnote trying to explain the relationship between the smart
contracts we're talking about and
On Mon, Jan 14, 2013 at 3:18 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Mon, Jan 14, 2013 at 6:05 PM, Mark S. Miller erig...@google.com wrote:
A fair point. By contracts in that first word, we refer to
real-world contracts. For software contracts, we initially had a
footnote trying to
On Mon, Jan 14, 2013 at 3:31 PM, Mark S. Miller erig...@google.com wrote:
On Mon, Jan 14, 2013 at 3:18 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Mon, Jan 14, 2013 at 6:05 PM, Mark S. Miller erig...@google.com wrote:
A fair point. By contracts in that first word, we refer to
On Mon, Jan 14, 2013 at 6:30 PM, Mark S. Miller erig...@google.com wrote:
The footnote I (again, perhaps unwisely) deleted is:
Although types as contracts [2] and higher order contracts [3] can be seen
as very
special cases of smart contracts, their purpose is typically different:
I don't have a good scenario at hand either that would require support for
surrogate code points, but in ECMAScript the question is often asked the other
way around: Why reject it? And given that there are several ways already to
construct strings that are ill-formed UTF-16 (e.g., \uD800,
It doesn't make sense and is illegal unicode. Eg: it's corrupt data. So the
only reason to accept it is to allow corrupt data, perhaps as a way of faking
other non-Unicode data as a Unicode context. Which inevitably leads to
problems, particularly on the web where people do whatever sneaky
Consider again the mixin scenario. A user wants to create a class with
private methods:
let privateMethod = new Symbol(true);
class C {
constructor() {}
[privateMethod]() { }
publicMethod() { this[privateMethod](); }
}
And then use that class as a mixin:
class D {
This is one thing that came to my mind a couple months ago, but there are a
number of ways to resolve this problem, such as:
function mixin(a, b) {
for (let name of Object.getOwnPropertyNames(b)) {
let desc = Object.getOwnPropertyDescriptor(b, name);
if
In order to satisfy security guarantees, properties which are keys on
private symbols are not returned by getOwnPropertyNames.
That's why the methods are bound to the original object.
I realize, however, that non-method properties don't work correctly this way
(so I probably just should
In order to satisfy security guarantees, properties which are keys on
private symbols are not returned by getOwnPropertyNames.
That's why the methods are bound to the original object.
Regardless of the this binding, the privately keyed method will not be
copied over from the source object
Regardless of the this binding, the privately keyed method will not
be copied over from the source object and hence will be undefined when
called.
I think you're not understanding. Here's a simpler example that runs in modern
ES engines:
var A = {
foo: function() {
uhm, you might be slightly behind current specs ... these changed proxy
quite a lot so that first argument is the target, and second argument is
the behavior.
var myProxy = new Proxy(target, handler);
at least that's how Firefox implemented it right now :D
var
target = {test:123},
proxy =
On Jan 14, 2013, at 9:32 PM, Dmitry Soshnikov wrote:
Hello,
Don't know whether it was mentioned/asked before (sorry if so), but just a
note: probably it makes more sense making the target argument as optional and
the second one in the Proxy constructor's API.
Proxy(handler[, target]):
On Jan 14, 2013, at 9:51 PM, Andrea Giammarchi wrote:
uhm, you might be slightly behind current specs ... these changed proxy quite
a lot so that first argument is the target, and second argument is the
behavior.
var myProxy = new Proxy(target, handler);
Oh, I'm aware about current
and `this` is the handler, not the target ...
var
handler,
target = {test:123},
proxy = new Proxy(target, handler = {
get: function ($target, key) {
alert($target === target); // true
alert(this === handler); // true
return $target[key];
}
})
;
The proxy target is important because it specifies some invariants about
the proxy (typeof, builtin brand, behavior of forwarding for unspecified
traps, values of internal properties like [[DateValue]], [[NumberValue]],
etc.).
On Tue, Jan 15, 2013 at 1:09 AM, Andrea Giammarchi
On Jan 14, 2013, at 10:40 PM, Brandon Benvie wrote:
The proxy target is important because it specifies some invariants about the
proxy (typeof, builtin brand, behavior of forwarding for unspecified traps,
values of internal properties like [[DateValue]], [[NumberValue]], etc.).
Sure, but
yep, same as asking for defineProperties with properties definition used as
class as unique required argument, it might make sense, but it's ok in
any case as it is
On Mon, Jan 14, 2013 at 10:50 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
On Jan 14, 2013, at 10:40 PM, Brandon
38 matches
Mail list logo
