Community
Participate
Working Groups
When I use CTRL + Space to propose name for a member of a class, I would like eclipse to prefix it by some prefix (in my case, "m_"). for example : class Foo { EventDispatch <CTRL + SPACE> } right now eclipse propose 'eventDispatcher' and 'dispatcher', which are both good names. I would like it to propose (in my case) 'm_eventDispatcher' and 'm_dispatcher'.
This is a nice feature that needs to be customisable rather that dictating some naming convention, but then you're probably leading to that. The question is how many prefixs would/could I define and hence how easy would it be?
I think there should be only one defineable prefix for member variables. one developer would not be likely to use two different codding standard within the same workspace. maybe we can also have defineable prefix for static members, for methods arguments, and for local variables. and above all, some people (I am not one of them), like to encode the type of the variable into the name, so we might add a map which maps type to prefix.
clearfication: I said 'and above all', not because I think its the most importent thing, but because it effects all the previous things I said in that message.
There is something related to this in Preferences / Java / Code Generation / Remove prefix from field names. Maybe this setting could be {re,ab}used to implement what you suggest. Regarding your suggestion to have only one defineable prefix for fields, prefix for static members, type-dependent prefixes etc. I think that's going a bit far. It's only a suggestion after all.
maybe you are right.
I tried to add that, but couldn't do it. The problem is that the name proposal algorithm is located in JCore's codeassist and JCore doesn't know anything about the field prefixes defined on JDT-UI preference page. We can't override the core behaviour from UI because core also does the filtering of proposals. EventDispatch f|<CTRL + SPACE will not give a callback for a variable completion, as core's proposals wouldn't start with 'f'. It would only come up on EventDispatch e|<CTRL + SPACE and propose eventDispatch My suggestion is that we move the name proposal algorithm to UI. Code assist should simply give callbacks of acceptVariableName on all offsets inside a variable. Moving to JCore for comments. see also bug 9092.
I am not sure adding an acceptVariableName callback will be enough. in order to generate the appropriate variable name proposal, the core needs to know about the user defined prefixs. I see several options: 1. have a setable strategy object. this way, the core will call external code that will know about user defined prefixes and will ask it to propose a name. I don't like this option very much. 2. add setMemberVariablePrefix(String prefixs[]) to some class in the core. this way, ui code will be able to configure the core based on user preferences. this option is not bad, although I think if you do it, you need to think well about other cases (such as local variables name proposal for example), because if future support will need to be wider, the API might chanage. Omry.
The JDT/Core callback suggests a variable name, which can be overhidden by the UI client. It passes along the type of the variable. However, it does not tell you about the variable location (field, local, argument, ...). So we may either want to pass additional information (hard since would change API), or add a couple more convenient settings to render JDT/Core aware of such prefixes.
We should make JDT/Core be aware of member prefixes.
I could add two new settings to JavaCore : - field prefix: when this setting have a value, a field name completion should begin with this prefix. - static field prefix: when this setting have a value, a static field name completion should begin with this prefix. Do you think this suggestion is correct and sufficient ?
Change target Milestone to M4
Note that we currenly support a list of field prefixes and list of field suffixes. I still think it would be better if all name guesing code would be grouped: I think it should be in JDT.UI but also jdt core could offer some API (e.g. INameGuesser) that also we can use. Another, API compatible, approach would be that code assist does not do name guessing but returns always -well known- names that signal the variable kind (e.g. 'fieldname', 'paramname', 'localname'). Code assist then wouldn't filter, but always return one of the given names. JDT.UI can then on top calculate the guess-names.
This would be a contract change, breaking other clients. Either we provide prefixes to JDT/Core, or we wait until 3.0 for a breaking API change (in which case I would vote for splitting acceptVariableName into - acceptLocalVariableName - acceptFieldName etc...
There is no promise to the client what names are returned by the ICompletionRequestor: In my opinion jdt.core is definitly free to always return a proposal called 'variable'. Another non-API breaking suggestion is to introduce an interface ICompletionRequestorExtension The API for codeAssist is still void codeComplete(int offset, ICodeCompletionRequestor requestor) the jdt.core implementation tests: if (requestor instanceof ICompletionRequestorExtension) ((ICompletionRequestorExtension)requestor).acceptLocalVariableName(...) You can then merge in this interface in 3.0 But as I said, its also fine for me if jdt.core offers a name guessing infrastructure that we could reuse.
The API extension sounds really a hack. It has been used in various place when it was critical only. Passing special variable names is doable, but this one is a contract change (not an API change, but the contract is broken). I agree at the moment it is not completely spec'ed, and we could change it, but existing customers would get broken. How critical is this feature ? I'd rather defer it until 3.0, where we can solve it at once.
for people using some prefix convention this is an important usability. It breaks the flow when you always have to go back and tweak the proposed name.
I added 8 JavaCore options and a new API class org.eclipse.jdt.core.NamingConventions. NamingConventions methods compute variable name and remove suffix/prefix. These changes are released in the last build (I20021213). Fixed.
New options : CODEASSIST / Define the Prefixes for Field Name When the prefixes is non empty, completion for field name will begin with one of the proposed prefixes. - option id: "org.eclipse.jdt.core.codeComplete.fieldPrefix" - possible values: { "<prefix>[,<prefix>]*" } where <prefix> is a String without any wild-card - default: "" CODEASSIST / Define the Prefixes for Static Field Name When the prefixes is non empty, completion for static field name will begin with one of the proposed prefixes. - option id: "org.eclipse.jdt.core.codeComplete.staticFieldPrefix" - possible values: { "<prefix>[,<prefix>]*" } where <prefix> is a String without any wild-card - default: "" CODEASSIST / Define the Prefixes for Local Variable Name When the prefixes is non empty, completion for local variable name will begin with one of the proposed prefixes. - option id: "org.eclipse.jdt.core.codeComplete.localPrefix" - possible values: { "<prefix>[,<prefix>]*" } where <prefix> is a String without any wild-card - default: "" CODEASSIST / Define the Prefixes for Argument Name When the prefixes is non empty, completion for argument name will begin with one of the proposed prefixes. - option id: "org.eclipse.jdt.core.codeComplete.argumentPrefix" - possible values: { "<prefix>[,<prefix>]*" } where <prefix> is a String without any wild-card - default: "" CODEASSIST / Define the Suffixes for Field Name When the suffixes is non empty, completion for field name will end with one of the proposed suffixes. - option id: "org.eclipse.jdt.core.codeComplete.fieldPrefix" - possible values: { "<suffix>[,<suffix>]*" } where <suffix> is a String without any wild-card - default: "" CODEASSIST / Define the Suffixes for Static Field Name When the suffixes is non empty, completion for static field name will end with one of the proposed suffixes. - option id: "org.eclipse.jdt.core.codeComplete.staticFieldPrefix" - possible values: { "<suffix>[,<suffix>]*" } where <suffix> is a String without any wild-card - default: "" CODEASSIST / Define the Suffixes for Local Variable Name When the suffixes is non empty, completion for local variable name will end with one of the proposed suffixes. - option id: "org.eclipse.jdt.core.codeComplete.localPrefix" - possible values: { "<suffix>[,<suffix>]*" } where <suffix> is a String without any wild-card - default: "" CODEASSIST / Define the Suffixes for Argument Name When the suffixes is non empty, completion for argument name will end with one of the proposed suffixes. - option id: "org.eclipse.jdt.core.codeComplete.argumentPrefix" - possible values: { "<suffix>[,<suffix>]*" } where <prefix> is a String without any wild-card - default: ""
Created attachment 2804 [details] The new API class
Be careful : There are errors in my previous comment and in the javadoc of JavaCore#getDefaultOptions() inside build I20021213. The options id are not good. The errors are only in the comment and the corresponding constants have the correct value. CODEASSIST / Define the Prefixes for Field Name When the prefixes is non empty, completion for field name will begin with one of the proposed prefixes. - option id: "org.eclipse.jdt.core.codeComplete.fieldPrefixes" - possible values: { "<prefix>[,<prefix>]*" } where <prefix> is a String without any wild-card - default: "" CODEASSIST / Define the Prefixes for Static Field Name When the prefixes is non empty, completion for static field name will begin with one of the proposed prefixes. - option id: "org.eclipse.jdt.core.codeComplete.staticFieldPrefixes" - possible values: { "<prefix>[,<prefix>]*" } where <prefix> is a String without any wild-card - default: "" CODEASSIST / Define the Prefixes for Local Variable Name When the prefixes is non empty, completion for local variable name will begin with one of the proposed prefixes. - option id: "org.eclipse.jdt.core.codeComplete.localPrefixes" - possible values: { "<prefix>[,<prefix>]*" } where <prefix> is a String without any wild-card - default: "" CODEASSIST / Define the Prefixes for Argument Name When the prefixes is non empty, completion for argument name will begin with one of the proposed prefixes. - option id: "org.eclipse.jdt.core.codeComplete.argumentPrefixes" - possible values: { "<prefix>[,<prefix>]*" } where <prefix> is a String without any wild-card - default: "" CODEASSIST / Define the Suffixes for Field Name When the suffixes is non empty, completion for field name will end with one of the proposed suffixes. - option id: "org.eclipse.jdt.core.codeComplete.fieldSuffixes - possible values: { "<suffix>[,<suffix>]*" } where <suffix> is a String without any wild-card - default: "" CODEASSIST / Define the Suffixes for Static Field Name When the suffixes is non empty, completion for static field name will end with one of the proposed suffixes. - option id: "org.eclipse.jdt.core.codeComplete.staticFieldSuffixes" - possible values: { "<suffix>[,<suffix>]*" } where <suffix> is a String without any wild-card - default: "" CODEASSIST / Define the Suffixes for Local Variable Name When the suffixes is non empty, completion for local variable name will end with one of the proposed suffixes. - option id: "org.eclipse.jdt.core.codeComplete.localSuffixes" - possible values: { "<suffix>[,<suffix>]*" } where <suffix> is a String without any wild-card - default: "" CODEASSIST / Define the Suffixes for Argument Name When the suffixes is non empty, completion for argument name will end with one of the proposed suffixes. - option id: "org.eclipse.jdt.core.codeComplete.argumentSuffixes" - possible values: { "<suffix>[,<suffix>]*" } where <prefix> is a String without any wild-card - default: ""
Verified.
