Auto trimming strings

[Shervin]

Hi.

I would like to see Lombok auto trimming strings. Perhaps as an
attribute to the data annotation, or @Trim or as an attribute to the
@Getter and @Setter.

That would be useful.

[Reinier Zwitserloot]

Not sure how to set this up in a way that doesn't lead to out-of-
control featuritis.

[Maaartin]

I agree, the next requirement could be normalizing unicode strings or
alike. But is there no way how to make it all customizable by letting
the users provide their own hooks? It could be complicated but the
gain would be enormous.

[Go Ki]

Hi,

I've been using Project Lombok for my own project (jpropeller). I've implemented a new annotation that uses first-class property fields to generate getters/setters. With this system it's pretty easy to implement things like trimming etc. without altering Lombok for each new requirement. I've put together some very simple code - this doesn't use jpropeller itself, it's just showing a much simpler version of first-class properties that achieve the trimming with the minimum fuss. 

The only new Lombok feature is the NodeRef annotation, which basically takes a field Property<T> someName and makes methods "T getSomeName()" and "void setSomeName(T t)". I can provide the source for the annotations in eclipse if anyone is interested - I haven't done a javac handler yet.

The actual jpropeller code uses more complex properties to provide for features like this, but also automatic propagation of changes, reactions (like calculations in a spreadsheet), thread safety, change notification, introspection without reflection, and an MVC system for easier UI creation.

===============TrimBean

package trim;

import lombok.NodeRef;

public class TrimBean {

@NodeRef

private final Property<String> name = Property.trimmer("Bob");

public static void main(String[] args) {

TrimBean b = new TrimBean();

System.out.println("'" + b.getName() + "'"); //Prints 'Bob'

b.setName("   lots of spaces    ");

System.out.println("'" + b.getName() + "'"); //Prints 'lots of spaces'

}

}

===============Processor

package trim;

public interface Processor<T> {

public T process(T value);

}

===============Property

package trim;

public class Property<T> {

private T value;

private Processor<T> processor;

public Property() {

this(null, null);

}

public Property(T value) {

this(value, null);

}

public Property(T value, Processor<T> processor) {

super();

this.value = value;

this.processor = processor;

}

public T get() {

return value;

}

public void set(T value) {

if (processor != null) {

this.value = processor.process(value);

} else {

this.value = value;

}

}

public final static Property<String> trimmer(String value) {

return new Property<String>(value, new Processor<String>() {

@Override

public String process(String value) {

return value.trim();

}

});

}

}

--
You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/

To post to this group, send email to project...@googlegroups.com
To unsubscribe from this group, send email to
project-lombo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/project-lombok?hl=en

To unsubscribe, reply using "remove me" as the subject.

[Reinier Zwitserloot]

Enormous gain? I don't see it that way.

I'll put down a strawman lombok-based version first:

@Data
@FieldAccessModifiers({StringTrimmer.class},
{UnicodeNormalizer.class})
public class Movie {
private final String name;
private final int year;
private final String director;
@Getter @FieldAccessModifiers(Normal.class)
private final String id;
}

Readable? At first look this doesn't really strike me as fantastic.
Let's contrast it to something like this:

@Data
public class Movie {
private final String name;
private final int year;
private final String director;
private final String id;

public String getName() {
return unicodeNormalize(name.trim());
}

public String getDirector() {
return unicodeNormalize(name.trim());
}
}

This presumes that equals and hashCode and toString get rewritten to
use getters and not the raw fields. I doubt the considerable
complexity of the first example is worth it; it's barely shorter.

NB: Go Ki, that looks awesome. Roel and I are explicitly holding back
on adding features to @Data and friends until we assess what a
property-based system can do.