Suggestion: Avoid direct prototype substitution

[brn]

This proposal now propose direct substitution to prototype. But I think it's not Ideal future Ecmascript way, and if protocol support implement function, it's more intuitive that implements implement function like below.

protocol Functor {
  map;
}

// If implementation is not satisfied, throw TypeError.
Protocol.implement(Array, Functor, {
  [Functor.map]: Array.prototype.map
});

What do you think?

[brn]

And If could, I would like to propose Open-class extension like below.

protocol Functor {
  map;
}

// We can implements protocol after declaration.
Array implements Functor {
  [Functor.map]: Array.prototype.map
}

[michaelficarra]

@brn This can already be done with existing mechanisms.

protocol Functor {
  map;
}

Array.prototype[Functor.map] = Array.prototype.map;

// If implementation is not satisfied, throw TypeError.
Protocol.implement(Array, Functor);

We don't have to worry about modifying built-in prototypes because the symbols are unique.

[brn]

@michaelficarra I know that symbol is unique and it's not break builtin prototype. But I want to say that 'prototype' property should be hidden and user shouldn't access directly. It's inconsistent because class mechanism hiding prototype, but protocol proposal require direct prototype property access. So It seems to me that it will back to ES5 era.

What do you think of that?

[ljharb]

@brn class isn't trying to "hide .prototype", and .prototype isn't "back to ES5". In the case of Array, it's not defined in your code by class. If you define it yourself, you don't have to reference .prototype at all.

Monkeypatching anything constructible in JS always requires interacting with .prototype - this isn't "ES5", this is "always and forever JavaScript".

[brn]

@ljharb That make sense. I was confused because ecmascript introduce class and I'm not need that and it seems to me that Ecmascript doesn't need that, so I think TC39 decide to hide prototype and wanna be more ordinal class base language. But I'm convinced that it remained prototype as monkey patching way and class intended to not hide prototype but behaving as just a syntax sugar.

@michaelficarra @ljharb Thank you for your time!