aboutsummaryrefslogtreecommitdiff
path: root/src/lombok/eclipse/handlers/HandleGetter.java
AgeCommit message (Collapse)Author
2009-07-26[TYPOS]Reinier Zwitserloot
2009-07-26[TRIVIAL]Reinier Zwitserloot
2009-07-26Addresses issue #4:Reinier Zwitserloot
If boolean fields already start with a typical getter prefix (is, has, or get), lombok's @Getter will no longer generate its own prefix as well, so a field named 'hasFoo' will result in a getter named 'hasFoo()', not 'isHasFoo()'. Also, if any likely getter name already exists for a boolean, a getter will not be generated. Thus, if your field is called 'hasFoo', and you already have a method named 'isFoo', then @Getter will not generate anything (and warn, unless the getter is being generated due to @Data). This last mechanism works by taking the field name *AND* any other likely base names (defined by the field name being named as prefix+baseName, with prefix being is/has/get), and then prefixing all the likely fieldnames with is/has/get, and checking if any method with that name exists. Of course, this means weird things are going to happen if you have 2 fields named 'isFoo' and 'hasFoo', but then, you'd be a real idiot if you did that.
2009-07-12More fixes to avoid erroneous "getter/setter is already there, not ↵Reinier Zwitserloot
generating it" warnings when the getter/setter already there was in fact generated by lombok, and fixed a bug in eclipse where a boolean array's getter method would be called isFoo() instead of getFoo().
2009-07-11The setter/getter handlers now mark themselves as not wanted to be called ↵Reinier Zwitserloot
upon anymore when reporting errors. They were logging 4 or more identical warnings per problem before this change.
2009-07-06Last massive documentation dump. All basic javadoc is now done, though ↵Reinier Zwitserloot
especially the docs on the lombok annotations in the lombok package need far more massaging. Also added a feature to HandleSynchronized to not auto-generate the locker fields if a specific name is provided (because, imagine you typoed those. You'd never find it!)
2009-06-28Preparating for java 1.5-ification. All stuff that isn't specific to javac ↵Reinier Zwitserloot
should run in java 1.5, so that an eclipse started on a 1.5 JVM will still run lombok.
2009-06-27Whoops - there was some debug printing left in eclipse's HandleGetterReinier Zwitserloot
2009-06-23Figured out that our previous act of just assigning TypeReference objects ↵Reinier Zwitserloot
directly to other nodes (e.g. from a FieldDeclaration's type to a method argument) is NOT a good idea, as this screws up when the TypeReference object represents a generic type (like 'T') - each instance of a generic type has a different resolution, but 1 TypeReference object can only hold 1 resolution. Thus, a copyType() method has been written, and the Handle* classes have been updated to use it. Also, generateEquals() is half-finished in HandleData.
2009-06-23This is a 3-day bughunt that ended up being something extremely simple:Reinier Zwitserloot
** DO NOT REUSE TYPEREFERENCE OBJECTS ** because that makes the binding process go pearshaped - after hte first run, that TypeReference object's binding parameter is set, and as its set, the resolver won't bother re-resolving it. However, each parse run starts with new scope objects, and any 2 bindings created by different scopes aren't equal to each other. urrrrrrgh! Fortunately, a lot of code that 'fixed' methods by adding bindings and scope have all been removed, as the parser patch point is well before these bindings are created. Thus: ** NEVER CREATE YOUR OWN BINDINGS AND SCOPE OBJECTS ** because if it comes down to that, you're doing it entirely wrong. That's eclipse's job. We're patching where we are so you don't have to do this.
2009-06-21Due to a java bug, constants in enums don't work, so instead the default ↵Reinier Zwitserloot
access level for @Getter and @Setter have now just been hardcoded in GetterHandler and SetterHandler. Added ability to look up the Node object for any given AST object on Node itself, as you don't usually have the AST object. Added toString() method generating to @Data, and this required some fancy footwork in finding if we've already generated methods, and editing a generated method to fill in binding and type resolutions. HandleGetter and HandleSetter have been updated to use these features. Exceptions caused by lombok handlers show up in the eclipse error log, but now, if they are related to a CompilationUnit, also as a problem (error) on the CUD - those error log entries are easy to miss! Our ASTs can now be appended to. When you generate a new AST node, you should add it to the AST, obviously. Getter/Setter have been updated to use this.
2009-06-19Added initial support for the @Data annotation. Currently produces getters ↵Reinier Zwitserloot
and setters only, not yet a constructor, toString, hashCode, or equals. HandleGetter and HandleSetter have been updated to handle static (theoretic; you can't put annotations on static fields normally). You can now make AnnotationValue objects using just an annotationNode and a target type, as well as check if a given annotationNode is likely to represent a target annotation type. This is in Javac and Eclipse classes. HandleGetter and HandleSetter can now be asked to make a getter/setter, and will grab access level off of a Getter/Setter annotation, if present.
2009-06-18Created a fully working HandleSetter for eclipse, and refactored ↵Reinier Zwitserloot
HandleGetter a little mostly to stuff common code into PKG.
2009-06-17AnnotationHandlers can now return a boolean to set if they actually handled ↵Reinier Zwitserloot
the annotation or not (previously, the presumption was they always handled the annotation). This is very useful for PrintAST on eclipse, because before this change, you'd never see method contents (as the initial dietParse would come first). Now Eclipse PrintASTHandler will skip any non-full runs, and only print non-diet. It then returns true only if it printed.
2009-06-17Renamed the Handler implementations.Reinier Zwitserloot