Closed Alex-At-Home closed 8 years ago
Instead of @TypeAliasesInside
this might be useful for all the generated code. So, maybe something like @HalvaContainer
which would work with any of the other code generators.
For 2 (The type alias seems to return the original class) - should the generator always recognize the parent type and wrap the result? I guess that's possible. I need to think about that a bit.
One of the common uses of type aliasing is to tidy up generics in local code, eg
There's a couple of issues with how that works at the moment:
1) Currently the type alias has to be declared in its own compilation unit, which makes the code much less local than you'd normally want. What would be really nice would be to be able to do something like
which would then generate
MyPackageAlias
containingStack
, ie my code inMyPackage
then usesfinal MyPackageAlias.Stack stack;
(note: I think the default unsuffix/suffix should be reversed for the inner type alias, ie user typesStackAlias
and the compiler generatesStack
).That way all my local type aliases remain local to my package, and the codebase is more compact.
2) The type alias seems to return the original class, eg:
I'm not sure that's the only reason, but one of the consequences of this is that the following code doesn't work:
You have to replace
StackAlias
withConsList<Integer>
inside theAny