(Resolved) Clarification: When are redefinitions allowed?

[jeffdyer]

I'm not sure it is specified anywhere, what are the rules for redefining fixtures? We have discussed it being possible to redefine fixtures with compatible types. beside requiring the analysis to be done at verify or eval time, this might not be what users expect. It seems unlikely that fixture annotated in different ways are intended to hold the same meaning.

I suggest we simplify the rule for allowing redefinitions to one of the following:

* if both overwriter and overwritee are unannotated

* if the overwriter or overwritee is unannotated

* if the overwriter or overwritee is unannotated or type *

In the 2nd and 3rd solutions, the fixture assumes the specific type, if there is one.

Graydon is implementing the 3rd solution. I think I prefer the 2nd one more because it is possible the user intended for the fixture to be generic if he explicitly annotated it with *.

[jeffdyer]

I will produce a matrix that shows the overwrite ability of different kinds of definitions in each context.

The definition kinds include: namespace, var, const, let, type, const function, function, class, interface, let const, let function

Contexts include: global, function, eval, class, interface, package, unit, block

possible states include: define once (1), {RO,DD}, anything goes

Jd

[brendan]

As we discussed in the face to face, it would be helpful to distinguish RO from replaceable, since function replaces prior var or function in ES1-3.

It would also help to have hoisting to variable scope vs. block scope indicated, with the implicit block around Program right-hand side kept in mind (does it delimit let bindings? yes; type bindings? no, not with a single global object).

/be

[lth]

Any progress on this?

[jeffdyer]

	        scope	attrs	global	class	func	block	es3 eval
let	        b	dd	-	-	-	1	-
let const	b	ro	-	-	-	1	-
let function	b	ro	-	-	-	1	-
var	        v	dd	2	1	2	-	2
function	v	dd	2	1	2	-	2
class	        v	ro	1	-	-	-	-
const	        v	ro	1	1	1	-	1
const function	v	ro	1	-	1	-	1
interface	v	ro	1	-	-	-	-
namespace	v	ro	1	1	1	-	-
type	        v	ro	1	1	1	-	-

legend:
dd	don't delete
ro	dd + write once
b	block scope
v	variable object scope
1	one binding only
2	rebinding allowed
-	never occurs because of hoisting or syntax error

notes:
- top-level blocks have the same binding semantics
  as their outer scope (e.g. global, class, function)
- packages are top-level blocks
- interfaces allow a single function declaration per name,
  and no other definition
- es4 eval has the same semantics as global bindings

[jeffdyer]

The above grid shows that the problem space is smaller than I had thought. Redefinitions are allowed only for ES3 style vars and functions, which I say hints at the solution. That is, we should allow rebinding only in the case of un-typed vars and functions, as described as the first option above. This is more restrictive than the RI or AS3, but is probably what most users would expect.

Jd

[jeffdyer]

Lars points out that rebinding rules should allow for invariant type annotations. This will allow users to add type annotations to ES3 code without erasing redundant definitions. He also suggests that it should be an error to annotate some, but not all, redundant definitions with the same type.

Jd

[jeffdyer]

SF f2f, agreement with lars propsoal above is reached. two additional points were made:

1/type equivalence is tested against the normalized form 2/errors are reported when the scope object is constructed

there is a question of when types can be normalized and whether they can be normalized in time to report the above error. this issue is likely resolved in the reference implementation (my opinion)

Jd