ES4 draft: Object initializers

Lars Hansen lhansen at adobe.com
Tue Apr 8 14:52:55 PDT 2008


> -----Original Message-----
> From: Mark S. Miller [mailto:erights at google.com] 
> Sent: 8. april 2008 15:38
> To: Lars Hansen
> Cc: es4-discuss at mozilla.org
> Subject: Re: ES4 draft: Object initializers
> 
> On Tue, Apr 8, 2008 at 12:20 PM, Lars Hansen 
> <lhansen at adobe.com> wrote:
> >  One facility that was introduced in this draft copies the type tags

> > of 'const' and 'var' attributed properties into  the type of the 
> > object, for "ease of use".  As a consequence,  this test is true:
> 
> I don't understand how this could work for "var".

The type is introduced on the fixture based on the initial
value; subsequent values will be constrained to be of
that type.  In terms of Draft 2,

  obj = { var x: "foo" }  // same as { x:"foo" } : { x:string }
  obj.x = "bar"           // ok
  obj.x = 37              // not ok

> >   { const x: "foo" } is { x: string }
> >
> >  I am going to remove that facility again because it violates  the 
> > "explicit is better than implicit" principle.  IMO the  programmer 
> > should state her intent:
> >
> >   { const x: "foo" } : { x: string }
> 
> A possible counter-argument is that the type of "foo" is 
> string rather than *. We don't make the programmer write
> 
>     "foo" :string
> 
> in order to get the right type.

It's true, we don't.  But object initializers evaluate to new
compound objects every time, not to immutable values that 
are ===, so I'm skeptical about the analogy.  The type of
an ES3 object initializer is 'Object' (not *).  And if all the
constituents of the initializer are literal expressions it's easy
enough to see what's going on.  But not if the constituents
are not literal expressions.

> >  (It's easy to say that when the literals are simple then the types
> > are obvious, but once they involve more complicated expressions I'm 
> > guessing the gains are illusory.)
> 
> That's not clear to me. The cases that come to mind compose well:
> 
>     { const x: { const y: "bar" } }
> 
> has type { x: { y: string }}

I'm more concerned about cases like this:

    { const x: f() }

which are quite opaque and where the object will have a type 
that depends on the value returned by f, possibly a different
type every time the initializer is evaluated.  It's not the
unbounded number of types that worries me but the fact that the
type of that expression is at the mercy of f.

--lars



More information about the Es4-discuss mailing list