Community
Participate
Working Groups
Days ago I wanted to find out what methods I would have to implement if I extended a particular abstract class and found out that if I position the cursor to the abstract keyword, nothing happens. I think a nice feature would be if the cursor is positioned on the abstract keyword and mark occurrences is on then the methods that make this class abstract would be highlighted.
Sounds like a cool feature. Just one remark: The reason why a class is abstract may not be an abstract method declared in this class, but abstract methods from the super-class or super-interfaces. So, I guess we would just expect these super-types to be highlighted as well, but only if inherited abstract methods are not implemented in the current class.
Move to JDT/Text
I'm not sure this is really helpful since as said in comment 1 you also might have to implement more methods. In addition you can - see the abstract methods in the Outline view or Quick Outline - use the quick fix to add the missing methods - use Source > Override/Implement Methods... No plans to do this.
(In reply to comment #3) > I'm not sure this is really helpful since as said in comment 1 you also might > have to implement more methods. In addition you can > - see the abstract methods in the Outline view or Quick Outline > - use the quick fix to add the missing methods > - use Source > Override/Implement Methods... > > No plans to do this. > Thanks for the information about, how to implement abstract methods in eclipse. I'm using Eclipse for four years now so I'm familiar with the methods described above. The fact that you provided this information means that you don't quite understand the intention here. The scenario I described was somewhat misleading as I was really trying to find out if I had to subclass the base abstract class or one of it's abstract subclasses and to highlight what will I have to implement and not wondering how to do it in eclipse. For me it was natural to place the cursor on the abstract keyword to highlight all of the abstract methods in that class the way methods highlight when I place the cursor on the Exception class in a catch statement. Another example: the hook methods highlighted in an abstract class by this feature. This has nothing to do with how to implement abstract methods. This feature would be about highlighting abstract methods (and in some cases the parent class as said in comment 1) in the same manner as highlighting anything else in the text editor. If you think this feature is useless that's fine with me but I had the feeling that it's not absolutely clear what the feature is.
You're right, I probably miss the point of your feature. You are saying: >For me it was natural to place the cursor on the abstract >keyword to highlight all of the abstract methods in that class You already see this by having the 'abstract' keyword, so I really can't see the additional benefit.
You probably also know this then: if you select an implemented interface or extended class it will highlight all the methods that belong to it.
(In reply to comment #6) > You probably also know this then: if you select an implemented interface or > extended class it will highlight all the methods that belong to it. > Yes, I'm familiar with that too, but it has nothing to do with this feature. A scenario could be: public abstract class Algorithm { public void calculate() { // do something //call hook hook1(); //call local method local(); // do something hook2(); } protected abstract void hook1(); protected void local() { // } protected abstract void hook2(); } If you place the cursor on the keyword abstract in row 1 then hook1 and hook2 method declarations get highlighted, this is what it's all about. As you can see it has nothing to do with the ancestors of this abstract class or implementing abstract methods.
(In reply to comment #5) > You're right, I probably miss the point of your feature. You are saying: > > >For me it was natural to place the cursor on the abstract > >keyword to highlight all of the abstract methods in that class > You already see this by having the 'abstract' keyword, so I really can't see > the additional benefit. > The benefit is that for example all the hook methods get highlighted in the example above and let me get this strait this has nothing to do with implementation. I really cannot understand what the problem is. Place the cursor on a constructor and all the constructors get highlighted in that class Analogy Place the cursor on the abstract keyword of an abstract method declaration and all the abstract methods get highlighted in that class
(In reply to comment #8) > (In reply to comment #5) [..] > > You already see this by having the 'abstract' keyword, so I really can't see > > the additional benefit. Maybe this is an even closer analogy: place the cursor on the return type of a method and see all return statements highlighted. This feature is not needed either, because we already have the "return" keyword, yet it is a tremendous help for quicker understanding without reading all the code, no? There might still be reasons not to implement this (rare use case, difficult to implement (modifier position might not be available?), unclear corner cases (abstract inherited)..) but I'd agree that it could be very helpful in certain situations.
The difference and hence added value in the return case is that it does not only highlight the return statements but also cases where the method is exited with exceptions.
(In reply to comment #10) > The difference and hence added value in the return case is that it does not > only highlight the return statements but also cases where the method is exited > with exceptions. > You are absolutely right, there is an additional benefit and we could argue on forever about if this is really a needed feature or not. But I'd rather not do that because I have a feeling that on your side this is already decided. What I'm sorry for is that you made this decision when you were misunderstanding the feature.
I'd like to add a meta suggestion: For RFEs that are about to be closed as WONTFIX not because its such a bad proposal, but because the need isn't felt strong enough for any committer to invest time, why don't you mark the issue as helpwanted and wait some time if people from the community like to contribute a solution.
We do this if we think this is a good feature that we do want but have no time for it. If we think the feature is not too useful it doesn't make much sense to ask for help.
(In reply to comment #12) > I'd like to add a meta suggestion: > > For RFEs that are about to be closed as WONTFIX not because its such a bad > proposal, but because the need isn't felt strong enough for any committer > to invest time, why don't you mark the issue as helpwanted and wait some time > if people from the community like to contribute a solution. > I appreciate your suggestion and thank you for your help, but I think I'll just close this issue.
Reconsidered, I don't think this is any worst then highlighting types. (for example if you highlight the type String).
Well, actually help is not wanted as we deem this feature not worthy. I'm leaving the bug open for now in case someone really wants this and implements it (off by default of course).
Seeing this issue still open I can't hold some more comments: (In reply to comment #16) > [...] (off by default of course). This doesn't sound very inviting :) I wouldn't expect that people actively search the preferences for enabling this kind of feature, but if I (without thinking much) select the word "abstract" and see all abstract methods highlighted I'd say "wow, cool, thanks for the info". I would expect "off by default" only for features that could potentially cause any kind of harm to some users (either the implementation is not stable/tested enough, or people would actually get slowed down in their daily work, etc.). I don't see any potential harm involved in this bug. Would external contributors really invest their time in a feature that is locked away behind some unknown preference option? I don't think so. By an analogy, how many users know of "Java Type Indicators"? Very few. I consider this a pity. Why should users "know" about it, why isn't it "just there", waiting to be *disabled* if it bugs someone? More to the topic of mark occurrences: since I mentioned marking the return type and seeing all return statements: I mentioned this because this is a really helpful feature for me, and most the time I use it I don't even realize that it would also mark exceptional exits. To me this shows that such marking can be very helpful even in cases that are not strictly necessary. Are you saying, you're not fond of this feature but wouldn't mind or would even appreciate if someone contributed it? Or are you saying you want this to not be part of the normal JDT behavior?
> Are you saying, you're not fond of this feature but wouldn't mind or would > even appreciate if someone contributed it? Or are you saying you want this > to not be part of the normal JDT behavior? See comment 3 for my opinion. I'm not begging for it ;-). But if people really want it and someone implements it in good quality, then that's fine but as said, it will be disabled by default because it shows redundant information and there are better ways to see or implement the abstract methods of a class.
