Re: Adding a non-class-syntax method for subclassing native objects

[Michael Theriot]

I believe you can do this with `Reflect.construct`.

```js
function SubArray(arg1) {
  return Reflect.construct(Array, arguments, SubArray);
}
SubArray.prototype = Object.create(Array.prototype);
Reflect.setPrototypeOf(SubArray, Array);

var arr = new SubArray();
arr instanceof SubArray; // true
arr instanceof Array; // true
arr[5] = 0; // should exotically update length property
arr.length === 6; // true
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Adding a non-class-syntax method for subclassing native objects

[Renki Ivanko]

It's currently impossible to inherit the behavior of exotic builtin objects
like `Array` without using the `class extends` syntax, which is surprising
to someone who has only seen the `class` syntax described as syntactical
sugar for prototypal inheritance, since it means that the `class extends`
syntax can't be fully desugared to the non-`class` syntax. It means that
describing the `class` syntax as syntactical sugar should be qualified to
be fully accurate (since trying to desugar it with, for example, Babel can
potentially break things even in browsers that otherwise support native
subclassing), and that non-`class` syntax is a second-class citizen in the
language. Adding a method for using the native subclassing without the
`class extends` syntax would be consistent with ES5 adding
`Object.create()` that allows using prototypal inheritance without the
`new` operator.

The new method could be called `Object.inherits()`; a simplified example of
how it could be used:

```class Foo extends Array() {}

// ...desugars to

function Foo() {
function Foo(...args) {
return Object.getPrototypeOf(Foo)(...args)
}

Object.inherits(Foo, Array)

return Foo
}

Object.inherits = function(subClass, superClass) {
subClass.prototype = Object.create(superClass.prototype, {
constructor: {value: subClass},
[Symbol.species]: {value: subClass},
})
Object.setPrototypeOf(subClass, superClass)
// make subClass imbue the objects it constructs with native exotic
behavior here
}```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: const VS features detection

[Gajus Kuizinas]

> I don't think this flies anyway. It has to be more like a function body,
otherwise var and function declarations would hoist out of it, which would
be insane IMO.
Agreed.
> Also, I really would want to avoid examples like [..]
Agreed.
> IIUC, the goal here is to allow a sequence of statements to produce a
value, not (necessarily) to allow arbitrary block semantics.
Agreed.
> strict function declarations don't hoist out of blocks, so the hoisting
issue is var only. I would find it surprising if var declarations did not
hoist out of do expressions.
If the intention is to have do-as-IIFE, then it would surprising to see var
host outside of a do expression.
> If all we want is sugar for IIFEs, I wouldn't bother. With arrow
functions, IIFEs are already a lot shorter. The extra brevity of do
expressions is not worth it.
I disagree. It is nice to be able to define a one-off IIFE. Furthermore,
wouldn't this allow a simpler GC implementation?
> I find the do{} solution more elegant and I believe this pattern ()=>{}()
will be abused pretty soon and JS will start looking like brainfuck but
that's another story I guess.
Agreed.
> I do have one usability concern with arrow IIFEs. I hate when I see them
written as ()=>{...whatever...}() because you don't know that it's an IIFE
until the end. Function expressions have the same issue.
Good point.
> Rather, I suggest that the following must work:> while (true) { do {
break; } }
I am surprised by this requirement. I don't think `do` should serve allow
control flow statements at all.
I would argue that `do` expression would be mostly useful for promoting use
of `const`, e.g.,
_.map(groupedEvents, (locationEvents) => {let locationName;
const locationEvent = locationEvents[0];
if (locationEvent.locationDisplayName) {locationName =
locationEvent.locationDisplayName;} else if
(locationEvent.cinemaIsPlatform)
{locationName = locationEvent.locationName;} else if (
isCinemaNamePartOfLocationName(locationEvent.locationName,
locationEvent.cinemaName)) {locationName =
locationEvent.locationName;} else {locationName =
locationEvent.cinemaName + ' ' + locationEvent.locationName;}
// ...
I would like to avoid using `let` in this case and `do` expression is great
for this:
_.map(groupedEvents, (locationEvents) => {let locationName;
const locationEvent = locationEvents[0];
const locationName = do {if
(locationEvent.locationDisplayName)
{locationEvent.locationDisplayName;} else if
(locationEvent.cinemaIsPlatform) {
locationEvent.locationName;} else if (
isCinemaNamePartOfLocationName(locationEvent.locationName,
locationEvent.cinemaName)) {locationEvent.locationName;
} else {locationEvent.cinemaName + ' ' +
locationEvent.locationName;}};
// ...
However, I do not like at all that `do` expression returns value of the
last statement. I would much rather prefer to have `return` to be able to
control return of the value within `do` expression, e.g.
_.map(groupedEvents, (locationEvents) => {let locationName;
const locationEvent = locationEvents[0];
const locationName = do {if
(locationEvent.locationDisplayName)
{return locationEvent.locationDisplayName;}
if (locationEvent.cinemaIsPlatform) {return
locationEvent.locationName;}
if (isCinemaNamePartOfLocationName(locationEvent.locationName,
locationEvent.cinemaName)) {return
locationEvent.locationName;}
return locationEvent.cinemaName + ' ' +
locationEvent.locationName;};
// ...
Has this discussion been moved to some other medium?
No messages have been exchanged since 2014. In the mean time, transpilers
such as Babel have implemented the proposal (
http://babeljs.io/docs/plugins/transform-do-expressions/) and are
"promoting" its use in the form of the original proposal.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss