Thanks Allen,
however you know which super will be and what that operation does once
invoked, right? Isn't toMethod bringing scenarios where you don't know what
that would do?
Isn't that mixin unusable for any other kind of object that is not
inheriting Map? The latter is the one that I don't get ... I can use
toMethod for something that will simply break or not behave as expected,
while what I'd like to do is to be sure that the Map method is used and
nothing else.
Thanks
On Tue, Dec 3, 2013 at 11:56 AM, Allen Wirfs-Brock <[email protected]>wrote:
>
> On Dec 3, 2013, at 11:28 AM, Andrea Giammarchi wrote:
>
> trying to understand in order to update a polyfill != emotional attached
> to mixin
>
> I find mixin useful for what it has always done until now (that is
> temporarily gone and it is un-shimmable due this new toMethod entry for
> what I can tell so it will likely not be adopted later on)
>
>
> Object.mixin was always unshimmable because of the its super rebinding
> semantics. See
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-mixinproperties
>
>
> Still very looking forward for a concrete example where `super()` that
> points to a different one after `toMethod()` is desired, thanks.
>
>
> The the last meeting we also decided to eliminate the comparator argument
> to the Map constructor because it only was useful for the case where you
> wanted to memoize -0.
>
> Here is a "mixin" object that can be used to selectively add that support
> to any Map instance to any Map subclass's prototype or to any object that
> exposes the Map interface:
>
>
> let MapM0 = (memo=> ({
> has (key) {
> if (Object.is(key, -0.0) return memo.has(this);
> return super(key);
> },
> get (key) {
> if (Object.is(key, -0.0) return memo.get(this);
> return super(key);
> },
> set (key, value) {
> if (Object.is(key, -0.0) return memo.set(this, value);
> return super(key, value);
> }
> }))(new WeakMap);
>
> Just mixin (using toMethod, or your own implementation of Object.mixin)
> the properties of MapM0.
>
> Allen
>
>
> On Tue, Dec 3, 2013 at 11:21 AM, Domenic Denicola <
> [email protected]> wrote:
>
>> I wish we'd never switched from Object.define to Object.mixin, since
>> people have such an emotional attachment to their conception of what the
>> word "mixin" means and it causes reactions like this. In that sense, I'm
>> glad it's gone from ES6.
>>
>>
>> ------------------------------
>> *From:* es-discuss <[email protected]> on behalf of Andrea
>> Giammarchi <[email protected]>
>> *Sent:* Tuesday, December 03, 2013 14:18
>> *To:* Brendan Eich
>> *Cc:* [email protected]
>> *Subject:* Re: any toMethod() use case ?
>>
>> I am the author of one of those github `Object.mixin` "wannabe shim"
>> and this is why I'd like to know how crucial/relevant would this toMethod
>> be for the implementation because it's un-shimmable for what I can tell if
>> not swapping a global `super` reference at runtime per each wrapped method:
>> a complete no-go that TypeScript itself should never adopt in my opinion.
>>
>> Moreover, I believe mixins should not bring multiple inheritance but
>> rather enrich objects and if a mixin calls its parent, that should be the
>> expected parent no matter where the mixin has been used to enrich another
>> object.
>>
>> This is why I am having some difficulty imaging a scenario where
>> toMethod is needed and still I haven't seen a code example that would
>> reflect some real-world scenario/case.
>>
>> I am just trying to understand and nothing else. Thanks for any
>> example/piece of code that shows why toMethod is needed/wanted/desired
>> instead of static/explicit super.method calls.
>>
>>
>>
>> On Tue, Dec 3, 2013 at 11:07 AM, Brendan Eich <[email protected]>wrote:
>>
>>> Andrea Giammarchi wrote:
>>>
>>>> Thanks Allen but you mentioned `Object.mixin` twice while this has been
>>>> abandoned
>>>>
>>>
>>> No, deferred -- but why does ES6 status matter? You seem to be
>>> impeaching toMethod not because it isn't useful, as Allen showed, but
>>> because something that would need it if self-hosted (Object.mixin) isn't
>>> standardized in ES6 as well. That doesn't make sense. If Object.mixin is in
>>> ES6, one use-case for toMethod is already "done".
>>>
>>> Anyway, Object.mixin should be done on github and win adoption. Probably
>>> libraries will do their own variations. They all need toMethod to cope with
>>> super.
>>>
>>> /be
>>>
>>
>>
> _______________________________________________
> 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
