review feature(import): add CtImport in the model #1707
Conversation
| public interface CtImport extends CtElement { | ||
| <T extends CtImport> T setKindImport(ImportKind importKind); | ||
|
|
||
| ImportKind getKindImport(); |
There was a problem hiding this comment.
should be getImportKind
surli
changed the title
|
@monperrus @pvojtechovsky @tdurieux Even if every test is not passing, I'm curious about your insight on this PR. In particular, concerning the changes in the architecture. CtImport extends CtReference and encapsulate a CtReference: it was easier for managing scanner, but I'm mixed about this architecture. I was first considering a CtImport as only extending CtElement. What seem the better choice for you? For now I propose to introduce CtImport in keeping the old behaviour of Spoon: imports are only contained in a CompilationUnit and are computed by ImportScanner. |
Interesting question! What is the difference between CtReference and CtElement? D2) CtReference has getDeclaration D3) CtReference has unsetable Comment So all 3 differences seems to be NOT fitting to CtImport extends CtReference. WDYT? Does any code which uses CtImport profits from |
|
|
||
| public class CtImportImpl extends CtElementImpl implements CtImport { | ||
| @MetamodelPropertyField(role = CtRole.IMPORT_KIND) | ||
| private ImportKind importKind; |
There was a problem hiding this comment.
what about
boolean includingChildren|
|
||
| @Override | ||
| public ImportKind getImportKind() { | ||
| return this.importKind; |
There was a problem hiding this comment.
what about
if (this.localReference instanceof CtTypeReference) {
return includingChildren ? STAR_TYPE : TYPE;
}
...
That would assure that code in ElementPrinterHelper#writeImports will always work
switch (ctImport.getImportKind()) {
case TYPE:
CtTypeReference typeRef = (CtTypeReference) ctImport.getReference();
importTypeStr = typeRef.getQualifiedName();
if (!isJavaLangClasses(importTypeStr)) {
setImports.add(importTypeStr);
}
break;
case STAR_PACKAGE:
CtPackageReference packageRef = (CtPackageReference) ctImport.getReference();
importTypeStr = packageRef.getQualifiedName() + ".*";
if (!isJavaLangClasses(importTypeStr)) {
setImports.add(importTypeStr);
}
break;
case METHOD:
CtExecutableReference execRef = (CtExecutableReference) ctImport.getReference();
if (execRef.getDeclaringType() != null) {
setStaticImports.add(this.removeInnerTypeSeparator(execRef.getDeclaringType().getQualifiedName()) + "." + execRef.getSimpleName());
}
break;
case FIELD:
CtFieldReference fieldRef = (CtFieldReference) ctImport.getReference();
setStaticImports.add(this.removeInnerTypeSeparator(fieldRef.getDeclaringType().getQualifiedName()) + "." + fieldRef.getSimpleName());
break;
case STAR_TYPE:
CtTypeReference typeStarRef = (CtTypeReference) ctImport.getReference();
importTypeStr = typeStarRef.getQualifiedName() + ".*";
if (!isJavaLangClasses(importTypeStr)) {
setStaticImports.add(importTypeStr);
}
break;
}There was a problem hiding this comment.
That would assure that code in ElementPrinterHelper#writeImports will always work
I'm not sure to understand your point here. You assume that the current implementation of ElementPrinterHelper#writeImports won't work in some cases?
IMHO includingChildren would give less information than ImportKind.
There was a problem hiding this comment.
I mean that current CtImport API is not safe for client's mistake. Client can create CtImport with kind = package, but providing CtTypeReference ... it is insconsistency.
That inconsistency might be solved if ctImport.getImportKind() would be DERIVED property and we would have instead CtImport#includingChildren which is not derived
|
Anyway I like this PR! It moves in good direction! |
I assume you mean
IMHO the
This is a real problem. I did not check that when I implement it.
It's hard to say as So maybe I can inherit |
Interesting idea ... |
I just made the changes: it shows that the Concerning CtComment I did not test for now to put comments on an import, I propose to see that later. |
|
|
||
| public enum ImportKind { | ||
| TYPE, | ||
| STAR_PACKAGE, |
There was a problem hiding this comment.
STAR_PACKAGE->ALL_TYPES
STAR_TYPE -> ALL_STATIC_MEMBERS
|
|
||
| // contract: the scan method is called with the same role as the one set on field / property | ||
| CtRole expectedRole = metaModel.getRoleOfMethod((CtMethod<?>)invocation.getExecutable().getDeclaration()); |
…sent import static type members reference
|
Detected changes by Revapi: 8. Old API: fr.inria.gforge.spoon:spoon-core:jar:6.1.0-20171123.234626-7 New API: fr.inria.gforge.spoon:spoon-core:jar:6.1.0-SNAPSHOT
|
|
@monperrus I propose to merge the PR as it is: your last comment concerning DefaultJavaPrettyPrinterTest is actually already checked few lines later, but not exactly with a call to Once we have this PR merged I want to check first if #1365 is improved, and then to completely refactor |
|
Week-end merge! Thanks a lot @surli |
|
Version : Spoon 7.0.0 I am facing the similar or same issue in Spoon 7.0.0. package com.somelocalpack; When I parse this class Set<CtTypeReference<?>> superInterfaces = element.getSuperInterfaces(); The superInterfaces ( MessageDrivenBean, MessageListener ) are identified as |
|
Thanks for the bug report. This is normal, because the jar file containing |
The goal of this PR is to manage imports properly with CtImport.