Feature request: Generate getters/setters for fields from super class

[Alex]

Hello,

I'm facing the following "problem".

I have a tool that creates classes with protected fields. These generated classes can't be changed.

In order to be able to use these fields, I write a custom "facade" class with only getter methods for the protected fields.

This is cumbersome especially if:

1) a field changes it's name

2) a field is added or removed

3) most importantly, if you are used to lombok and never write getters or setters :-))

I was wondering if it would be possible to add an annotation at the class level that would produce the getters and/or setters for the protected fields in the super class.

Here's an example:

public class MyDesign {
    protected Button button1;
    protected Button button2;
    protected TextField field1;
    protected TextField field2;
}

now the facade class with possible annotation:

@Data(gettersFromSuper = true, settersFromSuper = false)
public class MyDesignFacade extends MyDesign {

}

would produce this code:

public class MyDesignFacade extends MyDesign {
    public Button getButton1() {
        return button1;
    }
    public Button getButton2() {
        return button2;
    }

    public TextField getField1() {
        return field1;
    }

    public TextField getField2() {
        return field2;
    }
}

Many thanks in advance for your feedback.

Alex

[Martin Grajcar]

I'm not a project owner, but I'd bet, this won't get implemented as it requires resolution, i.e., accessing other classes. Lombok can do, but only in a fragile and time-consuming way, so it gets used only for maybe two features.

I guess, you have some other good options. As you need a new class, a standard annotation processor should do (and writing it is an order of magnitude easier than extending Lombok; note that an annotation processor need no annotation in order to work, so you don't need to modify MyDesign). Sometimes even plain reflection can do it (it feels wrong as you first need to compile and load some classes before you can generate others, but it's simpler than annotation processing).

I don't really like using a facade, if I can avoid it, as then I have two classes where I want only one. If modifying the generated classes is not forbidden by the license or impossible for other reasons, I'd go for it. Obviously, any manual operation is out as it implies repeated work. But automated editing should be simple... maybe you could easily edit the sources, maybe the class files (ByteBuddy is your friend).

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombok+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Reinier Zwitserloot]

Cool idea, but not gonna make it, for two reasons:

A) It requires resolution. We can do that, but it's very complicated and brings a large maintenance burden (resolution-requiring stuff breaks far more often. It's also much slower to execute so it requires us to do a lot of performance tuning).

B) This is a very exotic usecase. Lombok tries to cater to the intersection of 'lots of ugly code that gets in the way of understanding what the code does', 'happens a lot', 'easy to fix and the fix has few to no hairy cornercases'. This just doesn't clear the bar.