Re: noSuchMethod: "funargs" + "invoke-only-phantoms"

if both V8 and SpiderMonkey will follow that logic to trap invoke-only method, I'll do my best to promote and explain how it works and why addressing anyhow does not make sense since there is nothing to address being inexistent. That case would be covered eventually by no such property but this on

Re: Are Private name and Weak Map the same feature? and the Assoc API

Thanks, Sam -- couldn't have said it better. /be - Original Message - From: "Sam Tobin-Hochstadt" To: "David Bruant" Cc: "Brendan Eich" , "es-discuss" Sent: Friday, December 16, 2011 3:24:42 PM Subject: Re: Are Private name and Weak Map the same feature? and the Assoc API On Fri, Dec

Re: Are Private name and Weak Map the same feature? and the Assoc API

On Fri, Dec 16, 2011 at 6:09 PM, David Bruant wrote: > >> Requiring you to care in order to avoid leaking private names is incredibly >> error-prone. > So is requiring you to care in order to avoid leaking the public -> > private map. It's no more, no less dangerous or error-prone. > If I have to

Re: Are Private name and Weak Map the same feature? and the Assoc API

Le 16/12/2011 22:03, Brendan Eich a écrit : > From: "David Bruant" >> ** if I trust a proxy, I share a: > Stop right there. You don't know whether another object passed to you is a > proxy or not. You cannot tell, in general. Nor should you have to care! I made a mistake when I talked about "tru

Re: <| ambiguity

Oh, thanks. I am sorry I had not read the proposal to the full detail. I just thought the operator always does the same thing no matter what the context is, but since it is not general, but tied only to some syntactic elements on RHS ({}, [], function, ...) than it is understandable that it ca

Re: Are Private name and Weak Map the same feature? and the Assoc API

From: "David Bruant" > ** if I trust a proxy, I share a: Stop right there. You don't know whether another object passed to you is a proxy or not. You cannot tell, in general. Nor should you have to care! Requiring you to care in order to avoid leaking private names is incredibly error-prone.

Re: <| ambiguity

No problem with re-posting a reply that you meant to be a reply-all. For the case of ClassConstructorFunction <| function (...) {...} the proposal does something exra: it makes the RHS.prototype (the 'prototype' property of the RHS) delegate via that object's [[Prototype]] internal property

Re: Are Private name and Weak Map the same feature? and the Assoc API

My answer is pretty much the same than the previous message Le 16/12/2011 21:03, David Herman a écrit : > On Dec 16, 2011, at 11:52 AM, David Bruant wrote: > >> However, I have questions and concerns about the public counterpart. >> Why does it exists? > It exists to prevent unintentionally leaki

Re: Are Private name and Weak Map the same feature? and the Assoc API

Le 16/12/2011 20:58, Brendan Eich a écrit : > From: "David Bruant" >> Let's say we have two attenuators (proxies which reduce your authority over >> a given object) constructors we'd like to compose: makeAttenuated1 and >> makeAttenuated2 >> - >> // assuming we have an object 'o' and a pri

Re: <| ambiguity

Hello, of course it does matter, when taken as a whole. I just wanted to say that the actual problem I was trying to address, that <| is to be used with prototypeObject, not with ClassConstructorFunction on the left side, is a problem if the left side, and literal (or not) is the right-side, w

Re: Are Private name and Weak Map the same feature? and the Assoc API

On Dec 16, 2011, at 11:52 AM, David Bruant wrote: > However, I have questions and concerns about the public counterpart. > Why does it exists? It exists to prevent unintentionally leaking private names. When you have a private name and you do a property get of another object, if that object do

Re: Are Private name and Weak Map the same feature? and the Assoc API

From: "David Bruant" > Let's say we have two attenuators (proxies which reduce your authority over a > given object) constructors we'd like to compose: makeAttenuated1 and > makeAttenuated2 > - > // assuming we have an object 'o' and a private name 'p' > var aao = makeAttenuated2(makeAtte

Re: Are Private name and Weak Map the same feature? and the Assoc API

Le 16/12/2011 18:18, Brendan Eich a écrit : > We are not "giv[ing] up on private names" -- you are really just talking a > bit too autodidactically here, frankly. Indeed. What I meant was "I do not mean that private names should be given up". French does not have a passive form (or at least it's r

Re: <| ambiguity

Please see http://wiki.ecmascript.org/doku.php?id=harmony:proto_operator -- the <| operator grammatically requires only literal object forms on its right. /be - Original Message - From: "Herby Vojčík" To: es-discuss@mozilla.org Sent: Friday, December 16, 2011 9:57:45 AM Subject: <| ambi

Re: Property vs Behavior inheritance

> I would argue that your quest can be fulfilled by class declarations that > desugar to object exemplars. Do you agree? > > Assuming that your class declarations resemble say Java's, then of course. > But if we have class declarations like Java's why do we care about object > exemplars? Beca

<| ambiguity

Hello, I have read some articles on wiki.ecmascript.org as well as some post here. It seems <| operator (which I only recently understood that it was probably meant to be the generalization arrow hollow top turned sideways :-) ) is used two ways. As I understand, it was proposed (and I am wit

Re: Are Private name and Weak Map the same feature? and the Assoc API

We are not "giv[ing] up on private names" -- you are really just talking a bit too autodidactically here, frankly. Private names and weak maps are observably different in ES.next as proposed. One example: proxies, where accesses of private-named properties trap with a public-name counterpart su

Re: Property vs Behavior inheritance

On Fri, Dec 16, 2011 at 9:01 AM, Axel Rauschmayer wrote: > Sorry I don't understand the question, or how it is related to my > quest. > > > I would argue that your quest can be fulfilled by class declarations that > desugar to object exemplars. Do you agree? > Assuming that your class declaratio

Re: Property vs Behavior inheritance

> Sorry I don't understand the question, or how it is related to my > quest. I would argue that your quest can be fulfilled by class declarations that desugar to object exemplars. Do you agree? -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ali

Re: noSuchMethod: "funargs" + "invoke-only-phantoms"

I don't think SHOUTING helps your argument. The key point is whether and how any user of an abstraction can know that a given method is first- or second-class. Some frameworks such as TIBET use second-class methods only. Others (E4X, ECMA-357 comes to mind -- users did and do trip over its inv

Re: Property vs Behavior inheritance

On Fri, Dec 16, 2011 at 7:42 AM, Axel Rauschmayer wrote: > I'll just re-state this paragraph to illustrate that the glass is half > empty: > > Unlike classes, object exemplars are just objects. There is no language > support for detecting a object exemplar; developers have no help in > avoiding p

Re: noSuchMethod: "funargs" + "invoke-only-phantoms"

sorry for the typo, this point was 1.2.2.1 yes, invoke that callback via cb.call(object, *"methodName"*, arguments) On Fri, Dec 16, 2011 at 5:30 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > you don't use apply randomly, you use apply for methods or getters knowing > there is a f

Re: noSuchMethod: "funargs" + "invoke-only-phantoms"

you don't use apply randomly, you use apply for methods or getters knowing there is a function there. __noSuchMethod__ is about NOT HAVING A FUNCTION there and if the property is not defined apply should fail as well as obj.undefined.apply would I still do not understand why we keep mixing up get

Re: Property vs Behavior inheritance

> I'll just re-state this paragraph to illustrate that the glass is half empty: > > Unlike classes, object exemplars are just objects. There is no language > support for detecting a object exemplar; developers have no help in avoiding > pernicious debilitating bugs caused by data values in base

Re: Property vs Behavior inheritance

On Fri, Dec 16, 2011 at 4:22 AM, Axel Rauschmayer wrote: > ... > How you work with object exemplars is almost like with classes: You have > to be aware which objects are exemplars and which ones are instances. A > useful sanity check could be to require an exemplar to have a constructor() > metho

Re: Property vs Behavior inheritance

Le 15/12/2011 23:38, John J Barton a écrit : > On Thu, Dec 15, 2011 at 10:58 AM, David Bruant > wrote: > >> Classless solutions need a compelling solution to this issue, >> that is, an operation on a list of vanilla objects that yields a >> class-like object.

Re: Property vs Behavior inheritance

> With object exemplars, you have: > > var jane = new Person("Jane"); > var Employee = Person <| { ... }; > > (Since I guess only long time readers of this newsgroup could understand what > you write above, let me give a capsule summary: > Employee becomes an object with a .prototype pro

Re: Are Private name and Weak Map the same feature? and the Assoc API

There is a paragraph in the original e-mail that I forgot. Adding it below: Le 16/12/2011 12:19, David Bruant a écrit : > Hi, > > I couldn't post on es-discuss yesterday, so I rewrote my message and > posted it on github [1]. Here is the markdown source: > > # PART 1: The same feature? > When look

Are Private name and Weak Map the same feature? and the Assoc API

Hi, I couldn't post on es-discuss yesterday, so I rewrote my message and posted it on github [1]. Here is the markdown source: # PART 1: The same feature? When looked abstractly, both private name and weak maps propose an equivalent feature: a mapping between 2 unforgeable references and a value.

Re: noSuchMethod: "funargs" + "invoke-only-phantoms"

Yep, no doubt, first-class "missed" methods win -- again, because the programmer can and has the complete right (by just looking at one line of a code) to rewrite simple invoke to `apply' (she don't have to think whether it's a virtual method or not). The only thing I wanted is to reduce broken co