Callable objects protocol

[Isiah Meadows]

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
contact at isiahmeadows.com
www.isiahmeadows.com

On Wed, Dec 5, 2018 at 12:27 PM Ranando King <kingmph at gmail.com> 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 <andrea.giammarchi at gmail.com> 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 <kingmph at gmail.com> 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 <isiahmeadows at gmail.com> 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 <andrea.giammarchi at gmail.com> wrote:
>>>>>
>>>>> > the apply hook needs objects anyway.
>>>>>
>>>>> I meant functions
>>>>>
>>>>> On Wed, Dec 5, 2018 at 1:33 PM Andrea Giammarchi <andrea.giammarchi at gmail.com> 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 <kingmph at gmail.com> 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 <andrea.giammarchi at gmail.com> 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 <thysultan at gmail.com> 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
>>>>>>>>> es-discuss at mozilla.org
>>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> es-discuss mailing list
>>>>>>>> es-discuss at mozilla.org
>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss