angular_analyzer_plugin icon indicating copy to clipboard operation
angular_analyzer_plugin copied to clipboard

Generics not instantiated in #refs

Open MichaelRFairhurst opened this issue 9 years ago • 3 comments

If you create a generic component

@Component(...)
class GenericComp<T> {
   T getter;
}

and you use it in a template, capturing it as a variable

<generic-comp #genericComp>...</generic-comp>
{{genericComp.getter.length}}

then the type parameters will be unresolved. In this case, we get the error that type T has no getter 'getter'.

It doesn't seem to result in many errors, because T knows its own bounds, but T is a private type to GenericComp and should not be used in an external template.

When we put the variable genericComp in scope with a type, we need to call something to the effect of typeSystem.instantiateToBounds(classElement.type) to get the proper type to use for that scoped variable.

MichaelRFairhurst avatar Dec 06 '16 22:12 MichaelRFairhurst

We don't support this in Angular Dart yet anyway, FWIW.

matanlurey avatar Dec 06 '16 22:12 matanlurey

Not sure exactly what you mean. Do you mean you can't instantiate them with explicit parameters like #genericComp<int> or something like that?

I've see a few generic components in some internal shared libraries, and when they are used they act like so:

   // best comparison to <generic-comp #genericComp></generic-comp>
   GenericComp /* no specification */ genericComp = new GenericComp /* no specification */ ();

  // best comparison to {{genericComp.getter.length}}
   genericComp.getter.length;

In dart this would not report an error because gc.getter is resolved to be of type dynamic. In fact, T is a private type to GenericComp, it has no definition anywhere but inside the class definition of GenericComp.

We just need to match that behavior, of T never leaking outside the class definition, and instead using a sane type instead (like dynamic in this case and using bounds otherwise #91). instantiateToBounds is what the analyzer server uses for this kind of no-specification initialization.

We already match the dart typechecker's behavior when doing things like <generic-comp [genericInput]="x"></generic-comp> #84, but this case of using #ref got missed.

MichaelRFairhurst avatar Dec 06 '16 22:12 MichaelRFairhurst

Yeah, what I mean is we don't support generics in # yet (and it's not a huge priority)

matanlurey avatar Dec 07 '16 00:12 matanlurey