Community
Participate
Working Groups
20050308 The existing API to construct a (qualified) name is public Name newName(String[] identifiers) It is really nasty to use when an existing (possibly qualified) string is available. AST#newName(String qualifiedName) would be nice to have
Assuming that there are no whitespace or unicode issues to deal with, the following snippet does the trick. Is this a common enough issue for clients to warrant a convenience API? public static void main(String[] args) { String qName = "org.eclipse.core.runtime.IWorkspace.IStatus"; AST ast = AST.newAST(AST.JLS3); Name n = null; StringTokenizer t = new StringTokenizer(qName,"."); while(t.hasMoreTokens()) { SimpleName s = ast.newSimpleName(t.nextToken()); if (n == null) { n = s; } else { n = ast.newQualifiedName(n, s); } } System.out.println(n); }
I think it would be better to use the Java scanner instead of the StringTokenizer so that unicodes, whitespaces and comments are correctly handled. It's better when not every client has to do this and even does it wrong. I think it fits nicely in the other AST factory methods and the AST even has a scanner instance readily available.
The AST methods are not generally in the business of parsing inputs; that's what the AST parser is for. This is why I'd like to understand where the concrete usecases are coming from. If unicodes, whitespaces and comments are involved, where on earth is the input string coming from? These kinds of features are normally found in snippets of source code, not in the string results returned from any of the JDT Core APIs.
The unicode idea was wrong, sorry, you are right. Even if taken from source we should probably preserve the usage of unicodes, and not translate them. Let's not focus on that, I'm fine if we use the string tokenizer. But I'm really convinced that having AST.newName(String) would be a benefit. AST.newName(String[]) is just not very easy to use. We have a util method ASTNodeFactory.newName() that does that, with 32 usages in quick fix, refactoring and infrastructure amongst them are: - creating a Name node a reference to an exception (aquired from binding.getQualifiedName()) - creating a name from referenced variables from source, (possibly) qualified for extract method (to be used as arguments for calling the newly created method) (Note that Dirk changed this code to use ast string placeholders because of it's easier to use API) - the import rewriter takes bindings or strings and returns type nodes (that may or may not be qualified depending if an import could be added for the given type). A type node is returned to be used with e.g. the ast rewriter (Contructing a type is more complicated but name nodes are the base parts for doing that)
As Martin said I always started to use string place holders due to that fact that there wasn't a convenient way to create name nodes from qualified names. So +1 from my side.
Added AT.newName(String) with following spec: /** * Creates and returns a new unparented name node for the given name. * The name string must consist of 1 or more name segments separated * by single dots '.'. Returns a {@link QualifiedName} if the name has * dots, and a {@link SimpleName} otherwise. Each of the name * segments should be legal Java identifiers (this constraint may or may * not be enforced), and there must be at least one name segment. * The string must not contains white space, '<', '>', * '[', ']', or other any other characters that are not * part of the Java identifiers or separating '.'s. * * @param qualifiedName string consisting of 1 or more name segments, * each of which is a legal Java identifier, separated by single dots '.' * @return a new unparented name node * @exception IllegalArgumentException if: * <ul> * <li>the string is empty</li> * <li>the string begins or ends in a '.'</li> * <li>the string has adjacent '.'s</li> * <li>the segments between the '.'s are not valid Java identifiers</li> * </ul> * @since 3.1 */ public Name newName(String qualifiedName) { Updated tests and release notes.
Verified in 20050330-0500
