typed objects and value types

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Apr 2 10:31:59 PDT 2014


quick feedback

   1. paper: all Cartesian examples forget to retrieve/assign this.x and
   this.y, i.e. `Cartesian . prototype .toPolar = function() {var r =
   Math.sqrt(x*x + y*y);}` ... I can guess those are initial own properties
   but after reading all examples without context I started doubting about it
   2. no idea why types shouldn't be initialized either with or without
   `new`, which is the most natural way to write objects in JS since kinda
   ever (new Point() VS Point() ... how about it's just the same as it is for
   new Object() VS Object() ... if String comes out as argument I call it
   shenanigans)
   3. I'd love to see this stuff in ASAP but I keep wondering why nobody is
   planning to show the type in these properties descriptors ... as discussed
   before, so that ...

```javascript

var a = new Int32Array(1);
a[0] = 1;
Object.getOwnPropertyDescriptor(a, '0');

// produces
Object {
value: 1,
writable: true,
enumerable: true,
configurable: true,
type: int32 // <========= this !
}

```

Overall I appreciate the work and the progress behind this topic, good
stuff.

Best Regards




On Wed, Apr 2, 2014 at 10:19 AM, C. Scott Ananian <ecmascript at cscott.net>wrote:

> Commenting on this same region:
> ```
> print(points[0].x); // 0 to start
> points[0].x = 1;
> print(points[0].x); // still 0
> points[0] = {x: 1, y: 2};
> print(points[0].x); // now 1
> ```
>
> There's no reason why we couldn't extend the grammar to handle this
> case, in the same way that `a.f()` has different semantics than `f =
> a.f; f();`.  That is, use the [Reference Specification Type] to treat
> field assignment differently, so that the semantics of:
> ```
> points[0].x = 1;
> ```
> are the same as:
> ```
> points[0] = { x: 1, y: points[0].y }
> ```
>
> For my own education, here's a rough draft of how the [runtime
> semantics of assignment] might look:
>
> AssignmentExpression[In, Yield] : LeftHandSideExpression[?Yield] =
> AssignmentExpression[?In, ?Yield]
>
> 1. Let *lref* be the result of evaluating *LeftHandSideExpression*
> 2. ReturnIfAbrupt(*lref*)
> 3. If Type(*lref*) is Reference, then
>     a. Let *baseref* be GetBaseReference(*lref*)
>     b. If *baseref* is a reference to a value type, then
>         i. Let *name* be GetReferencedName(*lref*)
>         ii. Let *oldval* be GetValue(*baseref*)
>         iii. Let *rref* be the result of evaluating *AssignmentExpression*
>         iv. ReturnIfAbrupt(*rref*)
>         v. Let *rval* be GetValue(*rref*)
>         vi. Let *newval* be a value type identical to *oldval* except
> that field *name* is set to *rval*
>         vii. Let *status* be PutValue(*baseref*, *newval*)
>         viii. ReturnIfAbrupt(*status*)
>         ix. Return *rval*
> etc
>
> Note that in step 3a I need to get a *reference to* the base value,
> rather than using GetValue(*lref*).  So the Reference specification
> type would have to cover two levels of indirection rather than one.
>  --scott
>
> [Reference Specification Type]:
>
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-reference-specification-type
> )
> [runtime semantics of assignment]:
>
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-assignment-operators-runtime-semantics-evaluation
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140402/5fc930e9/attachment.html>


More information about the es-discuss mailing list