Discuss
  • Typed Objects and Classes

Typed Objects and Classes

# Brian Barnes (8 years ago)

As far as I can read, Typed Objects/Structs are in consideration for a later version of ecmascript (but not in the spec) and there exists some implementations. It depends on the engine, but has there been any thought to how costly they might be to fake at least some rudimentary type support? For instance:

class point2D { constructor() { this.props=new Structure({ x:uint32, y:unit32 }); }

setMe(x,y) {
	this.props.x=x;
	this.props.y=y;
}

}

This doubles the property lookups but that can probably be optimized away (maybe) -- but it does force the engine to consider x/y as always ints. Of course, this doesn't do anything about the function signatures.

I don't think types are coming anytime soon, and just wondering if, in the future, messy code like this might be worth it, or otherwise, to let implementers know this is something that people might try with their code and would be an interesting path to look at.

[>] Brian

# Isiah Meadows (8 years ago)

For what it's worth, engines already optimize for static object layouts. So if you never change the property set for instances of that class, the struct won't help performance much in practice. Similarly, standard arrays with just numbers are almost as fast as typed arrays as well, so unless you're in serious performance critical, likely asm.js, code, you might get a 0.5% boost.

# Brian Barnes (8 years ago)

OK, thanks, that answers my question!

[>] Brian

# Igor Baklan (8 years ago)

By the way it looks very similar to js-ctypes/StructType Although it designed for interoperability with native code (not for code performance improvement, or better code readability), it still might be interesting for you (more links can be found at wiki/Libffi/JavaScript )

# Andrea Giammarchi (8 years ago)

FWIW I once proposed to add type as descriptor property (and without success) so you could:

Object.defineProperties(
  Person.prototype,
  {
    age: {type: 'number', value: 0},
    name: {type: 'string', value: 'anonymous'}
  }
);

in order to have a "type" defined and inheritable avoiding de-opt but throwing instead when it's not the expected one.

It could be used to also promote an "un-typed" property like:

var obj = {id: 'abc-123'};
// later on
Object.defineProperty(obj, 'id', {type: 'string'});

And throw if different or if it was type defined already.

The type would work with get/set too, as well as enumerable, configurable, and writable properties.

It'd be fully backward compatible (ignored) and easy to transpile via flow like syntax.

It could also be polyfilled.

TL;DR nobody liked it ^_^

# Isiah Meadows (8 years ago)

Descriptors are annoying to deal with, anyways IMO. If it had a corresponding syntax, and if you could use functions/object prototypes to type them, they might have had a little better traction, but here's my opinion: anything type-wise that can change at runtime (like the descriptor proposal) doesn't seem likely to gain much traction mainly because 1. it's no better than the inline caches used now, and 2. types that are added at runtime can't be statically analyzed (which is why people use type annotations in the first place), and thus don't scale at all. That means likely resistance from both implementors and users at scale, which basically equates to it's not likely.

# Andrea Giammarchi (8 years ago)

You summarized the "nobody liked it" bit of my post. I just wanted to add some background to this discussion.