@typedefs with values

[John Lenz]

There has been a couple of attempt to use @typedefs in unique ways recently and we need to decide if we want to encourage or discourage these practices:

case 0: standard practice

/** @typedef {string} */  var X;

case 1: type alias

/** @typedef {Foo} */ var Bar = Foo;

case 2: namespace with a type

/** @typedef {string} */ var Bar = {};

Bar.X = 1;

case 3: random value

/** @typedef {string} */ var Bar = true;

/** @typedef {Foo} */ var Bar = new Foo()

0 obviously we support, 1 seems natural enough and I'm working on fixing collapse properties so this actually works.  

Case 2, has some use and works today but I'm concerned that we might be incurring engineering debt if we allow it.  

Case 3, seems most likely typos and we should ban them

[John Lenz]

+malte

[Dimitris Vardoulakis]

I don't get case 1. Should it be

/** @typedef {Foo} */ var Foo = Bar;

??

If not, where else is Foo defined and can appear as an rvalue here?

If yes, can't we just write

/** @typedef {Bar} */ var Foo;

and get the same thing?

Also, I don't think we should support 2 and 3. Typedef is meant to be a shorthand for an already defined type, and that's it. (I don't have an opinion on case 1 yet b/c I don't fully understand what it does.)

--
Dimitris

[Nick Santos]

That's odd. I thought we used to explicitly forbid 1-3, by giving
the typedef variable a NoneType. Did that break?

[Chad Killingsworth]

John: In case 1, does that work with anonymous types? If so, that should solve https://code.google.com/p/closure-compiler/issues/detail?id=448

 

I don't understand what's going on in case 2. I agree that case 3 should not be allowed.

 

Chad

[John Lenz]

If so, it has been broken for a while.

[John Lenz]

Clarification for 

Case 1:

/** @constructor */

function NewName() {}

/** @typedef {NewName} */

var OldName = NewName;

var y = new NewName();

goog.asserts.assert(y instanceof OldName);

--
 
---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dimitris Vardoulakis]

Thanks for the clarification John. Now that I understand, my opinion is that we shouldn't support case 1.

--
Dimitris

[John Lenz]

Can you outline your line of reasoning?  This is the one case I would like to support.

[Dimitris Vardoulakis]

Typedef usually introduces a new type name as an alias for an existing type. Can we get what case 1 does by writing

/** @type {NewName} */

var OldName = NewName;

instead of 

/** @typedef {NewName} */

var OldName = NewName;

?

[Nick Santos]

We already support:
/** @constructor */ var Foo = Bar;
and
/** @enum */ var Foo = Bar;

right?

Using @typedef for this makes it look like more complicated forms will
work, i.e.,
/** @typedef {Bar} */
var Foo = someExpr;
when in fact they will not.

[John Lenz]

no, @type is an instance of NewName.  @typedef declares it to be the Type.

Consider:

/** @type {String} */

var Alias = String;  // Error Function is not a String

new Alias(); // Error a String instance is not a constructor, can not be called with new.

/** @typedef {String} */

var Alias = String;  // no typecheck here

new Alias(); // Alias is a another name for the String constructor, ok.

[Dimitris Vardoulakis]

I see. What about Nick's examples? Would these be enough for the OldType/NewType aliasing? Or is there more to typedef-case1?

[John Lenz]

On Fri, May 17, 2013 at 11:08 AM, Chad Killingsworth <chadkill...@missouristate.edu> wrote:

John: In case 1, does that work with anonymous types? If so, that should solve https://code.google.com/p/closure-compiler/issues/detail?id=448

How would I refer to the anonymous type in typedef declaration?

 

 

I don't understand what's going on in case 2. I agree that case 3 should not be allowed.

 

In case 2, the type name and the slot type are different.  It is being used as a namespace.

I don't completely understand why it is useful either, except you can associate some values with the type.

 

--

[John Lenz]

Yes, I think Nick's examples are sufficient.  I'll try it out.

/** @const */

var OldNameSpace = NewNameSpace;

/** @constructor */

var OldConstructor = NewConstructor;

/** @enum */

var OldEnum = NewEnum;

[Nick Santos]

I can certainly understand the argument that
/** @typedef {Bar} */ var Foo = Bar;
is just a more "intuitive" syntax for a constructor alias.

So I do think it would be reasonable to allow this, as long as we
clearly define what forms are allowed on the right-hand-side

But I also think it would be reasonable to forbid it if it really is
redundant with existing syntaxes.

[John Lenz]

For Case 1, I just want a syntax and I didn't think about use @constructor and @typedef worked for me but the other use cases made me concerned.  If we have other options, I happy to tighten down the definition.

[Johannes Nel]

From what I have read, case 1 does not provide very good type checking at runtime (http://closuretools.blogspot.co.uk/2012/02/type-checking-tips.html), should case 1 not perhaps result in a warning. 

Cases 2 seems the product of bad type checking and although legit in JS should be banned imo, case 3 makes little sense since the compiler supports union types and if I see something like that I would assume it is a bug.

j:pn
\\no comment