Typed properties beside Typed Objects
Andrea Giammarchi
andrea.giammarchi at gmail.com
Tue Mar 11 10:00:53 PDT 2014
Opening a new thread since the topic chosen for the enriched descriptors
was misleading and I didn't manage to explain what I was trying to achieve.
**Typed Objects**
Using `StructType`, as [described here](
http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects) we can define
static "classes" or "types" so that
```javascript
const Point2D = new StructType({x: int32, y: int32});
```
This means that every `Point2D({x: 1, y: 2})` object will have some sort of
special descriptor for those two properties, at least behind the exposed JS
scene.
Accordingly, I wonder if it makes sense to introduce another descriptor
property named `type` where such type could be any type accepted by
`StructType` properties.
These [types are described here](
http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects#types) and it
could be used as descriptor property so that:
```javascript
const Point2D = new StructType({x: int32, y: int32});
let p0 = Point2D({x: 1, y: 2});
Object.getOwnPropertyDescriptor(p0, 'x');
/*
{
writable: true,
enumerable: true,
configurable: false,
type: int32 // <=== this !
}
*/
```
In a world where **optional JS types** are introduced, if specified,
implicitly defaulting to `Any` if missing, it would ideally be possible to
define typed properties in dynamic shaped objects too, granting type
consistency for the developer, and giving the ability to the JS engine to
optionally optimize operations per most common types such string, boolean,
or any sort of number or statically shaped entity so that not only
`StructType` would benefit from a theoretical performance boost.
**Backward Compatible**
Having an implicit default to `Any` means that this `type` descriptor
property could be simply ignored or implemented as _always Any_ in ES5 or
ES6 compatible engines but a simple library that wraps `Object.create`,
`Object.defineProperty`, and `Object.defineProperties` upfront and can be
simply not used in production could bring already these types in all ES5+
engines, as [this library does already](
https://github.com/WebReflection/define-strict-properties#define-strict-properties
).
As Summary
I hope I've better explained what I meant in the other thread when I was
talking about extra properties ... not because I wanted my own custom
properties going all over the place with or without Proxies, simply to
bring these extra properties to the plate. `type` is only the first of
those proposed in there, but it's also the most important one.
Thanks for your thoughts, questions, or possible improvements on this.
Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140311/733a3ca0/attachment.html>
More information about the es-discuss
mailing list