BTW, another reason I want that kind of "function literal" is because I deliberately want to not just expose a function, but expose one *with properties*, as part of a public API.
----- Isiah Meadows [email protected] www.isiahmeadows.com On Wed, Dec 5, 2018 at 12:27 PM Ranando King <[email protected]> wrote: > > Andrea, if class-fields becomes the accepted standard for private then that > would work, but it's awfully redundant. A closure is the very definition of > "private" in ES. So what does it mean to have a `static #foo` lexically > declared? From inside the function, it would be no more private than `var > bar`. That would lead to confusion. See the problem? > > On Wed, Dec 5, 2018 at 10:02 AM Andrea Giammarchi > <[email protected]> wrote: >> >> I don't think introducing `public` here has any value. We have `static #a = >> 1` eventually for private already, the default should follow the classes >> behavior, IMO >> >> On Wed, Dec 5, 2018 at 10:46 PM Ranando King <[email protected]> wrote: >>> >>> That's the kind of thing I was shooting for with static lexical scope >>> variables. There's 2 problems with it given the way things are going >>> though. Take a look. >>> >>> ```js >>> function foo() { >>> static a=1, >>> b=2, >>> c=3; >>> } >>> ``` >>> By the way I'm thinking, this would create 3 static variables within foo >>> that are only initialized once and retain whatever value is set on them >>> across invocations. Basically, the object `foo` carries around a closure >>> containing those values. Problem is, this is private to foo. That conflicts >>> with class-fields and it's sigil-means-private model. >>> >>> Ignoring that, public static variables can also be done (but it'd be the >>> first ever introduction of `public` in ES. >>> ```js >>> function foo() { >>> static public a=1, >>> b=2, >>> c=3; >>> } >>> ``` >>> This would make `foo.a`, `foo.b`, & `foo.c` accessible as public properties >>> of `foo`. >>> >>> Think this needs to be a proposal? >>> >>> >>> On Wed, Dec 5, 2018 at 1:39 AM Isiah Meadows <[email protected]> wrote: >>>> >>>> Personally, I'd prefer something else: a means of a function object >>>> literal that's still callable, but I can tack other properties to it >>>> easily. Something like this, maybe: >>>> >>>> ```js >>>> { >>>> (...args) { ... }, >>>> } >>>> ``` >>>> >>>> In this, the `this` value is set to the callee itself, not the given >>>> `this` value. >>>> >>>> Not married to the syntax, but I want the functionality. >>>> On Wed, Dec 5, 2018 at 01:34 Andrea Giammarchi >>>> <[email protected]> wrote: >>>>> >>>>> > the apply hook needs objects anyway. >>>>> >>>>> I meant functions >>>>> >>>>> On Wed, Dec 5, 2018 at 1:33 PM Andrea Giammarchi >>>>> <[email protected]> wrote: >>>>>> >>>>>> I've actually replied to the op, I didn't mean to answer you directly, >>>>>> but the only reason I wrote that is because I could, no other reasons. >>>>>> >>>>>> However, people unaware of the handleEvent pattern for event listeners >>>>>> often hope to be able to pass objects as listeners, ignoring the fact >>>>>> they can do that already (but they need a handleEvent method, own or >>>>>> inherited, in that object). >>>>>> >>>>>> There is at least another use case I can't remember now, but I do >>>>>> remember doing the Proxy dance before ending up realizing that the apply >>>>>> hook needs objects anyway. >>>>>> >>>>>> But yeah, I don't think it's a must have, specially because we can have >>>>>> something similar already, as shown in my example. >>>>>> >>>>>> >>>>>> On Wed, Dec 5, 2018 at 1:25 PM Ranando King <[email protected]> wrote: >>>>>>> >>>>>>> Maybe I asked it wrong. >>>>>>> >>>>>>> How is making an ordinary object callable at all useful for anything >>>>>>> that can't already be easily handled via objects and functions? >>>>>>> (looking for use cases here) >>>>>>> How does this make coding easier to do and understand? (for the AST >>>>>>> parser and for the human) >>>>>>> >>>>>>> On Tue, Dec 4, 2018 at 11:54 PM Andrea Giammarchi >>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> How about this: >>>>>>>> >>>>>>>> ```js >>>>>>>> >>>>>>>> // the poly >>>>>>>> if (!Symbol.callable) >>>>>>>> Symbol.callable = Symbol('callable'); >>>>>>>> >>>>>>>> // the setup >>>>>>>> class Callable extends Function { >>>>>>>> constructor(object) { >>>>>>>> super('return arguments.callee[Symbol.callable](...arguments)'); >>>>>>>> // sloppy mode FTW! >>>>>>>> Object.setPrototypeOf(this, object); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> // the example >>>>>>>> const obj = new Callable({ >>>>>>>> [Symbol.callable](value) { >>>>>>>> return value + this.value; >>>>>>>> }, >>>>>>>> value: 123 >>>>>>>> }); >>>>>>>> >>>>>>>> obj(7); // 130 >>>>>>>> >>>>>>>> >>>>>>>> ``` >>>>>>>> >>>>>>>> On Wed, Dec 5, 2018 at 12:02 AM Sultan <[email protected]> wrote: >>>>>>>>> >>>>>>>>> Something along the lines of Symbol.iterator protocol for defining >>>>>>>>> callback objects i.e: Symbol.callable: >>>>>>>>> >>>>>>>>> const obj = { >>>>>>>>> [Symbol.callable]: function (...args) { return >>>>>>>>> this[Symbol.for('value')] }, >>>>>>>>> [Symbol.for(''value')]: 'value', >>>>>>>>> } >>>>>>>>> >>>>>>>>> assert(obj() === 'value') >>>>>>>>> _______________________________________________ >>>>>>>>> es-discuss mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> es-discuss mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
