Ideas on type hinting and named parameters

Luke Scott luke at webconnex.com
Tue Jun 9 15:30:49 UTC 2015


On Jun 9, 2015, at 1:57 AM, Andrea Giammarchi <andrea.giammarchi at gmail.com<mailto:andrea.giammarchi at gmail.com>> wrote:

quick personal thoughts on this matter, leaving the named arguments part beside (as it is looks kinda redundant/unnecessary effort that could wait)

We've been talking about types for long time in here and the good old direction was *binary data* in the form of `StructType`

```js
const Point2D = new StructType({x:uint32, y:uint32});

let xy = new Point2D({
  x: 0,
  y: 0
});

```

Not only this option looks and feel more consistent with typed options we have already in core such `Int32Array` and others, but it will be way easier to gracefully migrate to such new pattern and fully, or partially, polyfill for older engines.

Back to typed Array, I think this:
```js
var xyz = new Int32Array([1, 2, 3]);
```

is better than:
```js
var xyz = [
  int32 = 1,
  int32 = 2,
  int32 = 3
];
```
or whatever repeated operation we could have per each `xyz` like variable of "that kind", so whatever would eventually work as StructType might be in my opinion more suitable.

  1. you recognize upfront what kind of duck you are working with
  2. you define such type once instead of each time, reducing errors/typos
  3. when you pass data around you can specify as example just `Point2D` instead of `Array<T Int32>` and friends that are imo not so nice to have in a scripting language
  4. we have already tools capable of bringing in types in similar fashion you proposed ... how about we do something better than some syntax tools friendly, instead of some syntax optimized for developers?

You are talking about new primitive types, right? I’m focusing mostly on class types and inheritance (instanceof checking). String, Number, and Boolean are special cases though.

`uint32` is not a reserved word as far as I know. Do we care that they aren’t? If not, I suppose `string` could be part of that list of primitive type symbols, right? In which case `name string` could be used instead of `name String`.

Is StructType passed by value or by reference? If by reference, wouldn’t that be a bit misleading? Structs are usually supposed to be cheaper than objects because of how / where they are allocated.

For structs I was thinking about something along the lines of:

```js
struct Point2D {
  x Number
  y Number
};
let xy = Point2D(x: 5, y: 10);
```

…which goes nicely with named arguments :).

Moreover about classes, you have defined properties that AFAIK are not allowed by current specs. ES6 classes accepts only methods and/or getters and setters so I'm not sure properties should be discussed together with types, maybe worth waiting for better understanding on how properties will be?

Class properties are listed in stage 0 here: https://github.com/tc39/ecma262/blob/master/stage0.md https://gist.github.com/jeffmo/054df782c05639da2adb

It currently uses `=` to define properties. And there is some debate whether or not properties should be initialized in the constructor or be on the prototype.

In the type-hinting repo I show both `=` and `:`, although I would prefer `:` to keep consistent with plain objects.

Thinking about how other proposals could overlap and trying to avoid any unnecessary conflict can be important.

That being said, I see why you used space instead of colon, and for literal objects that indeed looks like a better approach.

Thank you your kind words. I’ll have to admit I was expecting more backlash. The day is still young though :)

Luke

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150609/2562bf7d/attachment-0001.html>


More information about the es-discuss mailing list