Refactor interpreted-data interface in preparation for other interpretations than SARIF#811
Refactor interpreted-data interface in preparation for other interpretations than SARIF#811hvitved wants to merge 2 commits into
Conversation
cc3aae5 to
fd79e86
Compare
| // Add more interpretation data kinds when needed (e.g., graph data) | ||
| export type InterpretationData = SarifInterpretationData; | ||
|
|
||
| export interface InterpretationT<T> { |
There was a problem hiding this comment.
| export interface InterpretationT<T> { | |
| export interface Interpretation<T> { |
| data: T; | ||
| } | ||
|
|
||
| export type Interpretation = InterpretationT<InterpretationData>; |
There was a problem hiding this comment.
| export type Interpretation = InterpretationT<InterpretationData>; | |
| export type Interpretation = Interpretation<InterpretationData>; |
There was a problem hiding this comment.
This doesn't appear to work, I guess you can't have both a generic type and a non-generic type with the same name?
| const data = resultSet.interpretation.data; | ||
| switch (data.t) { | ||
| case 'SarifInterpretationData': { | ||
| const sarifResultSet = { ...resultSet, interpretation: { ...resultSet.interpretation, data } }; |
There was a problem hiding this comment.
This is confusing to me. It doesn't look like anything is changing here. Could you add a comment to explain what you're doing?
There was a problem hiding this comment.
Right, this dispatch on t only makes sense when we have other interpretation types, so I can move it in to the other PR.
| readonly schema: ResultSetSchema; | ||
| name: string; | ||
| } & Interpretation; | ||
| interpretation: InterpretationT<T>; |
There was a problem hiding this comment.
| interpretation: InterpretationT<T>; | |
| interpretation: Interpretation<T>; |
|
|
||
| export interface Interpretation { | ||
| export type SarifInterpretationData = { | ||
| t: 'SarifInterpretationData'; |
There was a problem hiding this comment.
Here, you are added a nested t field. This seems to complicate things somewhat. Would it make sense to keep only one t field at the top level, and specify RawResultSet, SarifResultSet, and (eventually) GraphResultSet?
I don't remember your other PR, so maybe there's a good reason to keep this.
There was a problem hiding this comment.
This is in preparation for
export type GraphInterpretationData = {
t: 'GraphInterpretationData';
dot: string[];
};(from the other PR) so we can do dispatch on the types (this is how to do tagged unions in Typescript, right?)
| @@ -53,9 +61,11 @@ export interface Interpretation { | |||
| * they appear in the sarif file. | |||
| */ | |||
| sortState?: InterpretedResultsSortState; | |||
There was a problem hiding this comment.
Does this field make sense for graph results?
There was a problem hiding this comment.
No, so I'll move it into SarifInterpretationData.
f3bab3a to
ab38077
Compare
|
Rebased to resolve merge conflicts |
ab38077 to
62d7669
Compare
62d7669 to
f6329f3
Compare
f6329f3 to
8980aa4
Compare
8980aa4 to
414ae7e
Compare
365d9fe to
4b0d090
Compare
4b0d090 to
442da0e
Compare
442da0e to
3f07d76
Compare
3f07d76 to
33aaf4a
Compare
33aaf4a to
51883ef
Compare
51883ef to
6ef287a
Compare
|
Superseded by #1111 |
Having this change in makes it easier to keep #705 up to date.