Summary: | Why is checking a modifier so code intensive | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Dirk Baeumer <dirk_baeumer> |
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | philippe_mulet |
Version: | 3.2 | ||
Target Milestone: | 3.2 M5 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Dirk Baeumer
2006-01-02 12:23:57 EST
If only interested in checking flags, you could use: (method.getModifiers() & Modifier.PUBLIC) != 0 But I agree, more convenience methods wouldn't hurt. What do you expect for this PR? New API? Actually I am checking flags and annotations. That's why I am iterating over all extended modifiers of the method declaration node. Do you suggest to add all these methods on org.eclipse.jdt.core.dom.Modifier? isPublic() isPrivate() isProtected() isStatic() isFinal() isSynchronized() isVolatile() isTransient() isNative() isAbstract() isStrictfp() +1 since this is what I expected to have when I typed in my code. The static methods were good to use when the modifiers where still encoded as flags (JSL2), but with JSL3 I think we should have corresponding instance methods as well. Fixed and released in HEAD. Added regression test in org.eclipse.jdt.core.tests.dom.ASTTest.testModifiers Also added regression test in org.eclipse.jdt.core.tests.dom.ASTConverterTestAST3_2.test0443 Verified for 3.2 M5 using build I20060215-0010. |