-
Notifications
You must be signed in to change notification settings - Fork 175
Make MultiTargetAnnotation type-parameterized and fix some comments #1230
base: master-deprecated
Are you sure you want to change the base?
Make MultiTargetAnnotation type-parameterized and fix some comments #1230
Conversation
One thing to point out is that this does have an API impact, since people would have to change code that extends |
|
||
/** Assume [[RenameMap]] is `Map(TargetA -> Seq(TargetA1, TargetA2, TargetA3), TargetB -> Seq(TargetB1, TargetB2))` | ||
* in the update, this Annotation is still one annotation, but the contents are renamed in the below form | ||
* Seq(Seq(TargetA1, TargetA2, TargetA3), Seq(TargetB1, TargetB2), Seq(TargetC)) | ||
**/ | ||
def update(renames: RenameMap): Seq[Annotation] = Seq(duplicate(targets.map(ts => ts.flatMap(renames(_))))) | ||
def update(renames: RenameMap): Seq[Annotation] = Seq(duplicate(targets.map(_.flatMap(renames(_).map(_.asInstanceOf[T]))))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might give a cryptic error if a rename violates the type constraints.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any suggested change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can think about non-intrusive ways to hide it from the user, but the TLDR is that casts to erased types can lead to class case exceptions in the caller's code. The normal Scala way to solve this is with ClassTag
s, but this is complicated for a trait and can clutter downstream code.
If someone uses a RenameMap
that has a record that renames a ReferenceTarget
to an InstanceTarget
or something, it would produce some crazy results.
@albert-magyar wouldn't it infer the type parameter to be Edit: never mind, I get what you are saying now. |
Unfortunately, it won't generally infer the type parameter for the trait, since Scala only has local type inference. Not saying that it's a problem (I personally don't think it is), but just clarifying for the sake of the issue template classification text. |
@albert-magyar Cool, I edited the classification in the first comment. |
I'll preface this by saying that I don't think this is a showstopper by any means, but more of a heads-up about the potential holes in the type safety of this parameter. As a concrete example of renames that do happen that could lead to type errors, The annoying part is that, type erasure can cause the
Unfortunately, using |
@albert-magyar What would happen if you used a |
It's generally pretty ugly, but the TLDR is that it does a duplicate call with the actual returned target inside The problem is that the contents of a |
Needs more thought, see Albert's comments
This PR adds a type parameter to
MultiTargetAnnotation
(#1109) to allow concrete subclasses to have stricter type checking oftargets
, if desired. I also cleaned up a few comment nits.Checklist
Type of Improvement
API Impact
API modification, but you can use the old behavior by using
Target
as type parameterT
. This allows stricter type checking of subclasses ofMultiTargetAnnotation
if desired.Backend Code Generation Impact
No change
Desired Merge Strategy