Is there any support for fluent getters in MapStruct? It seems that inspection of methods is done by method name. And so with fluent getters that have no prefix, everyone method could seem like a getter.
Has anyone tackled this problem?
MapStruct does not support fluent getters. The reason for that is that fluent getters means every single method without parameters that returns non void type.
However, if you have some kind of annotation or some kind of rule that you can enforce for fluent getters then you can have a look at the AccessorNamingStrategy and provide your own implementation.
Related
I would like to map the source object to target but in my model I m using the different naming convention for getters
//instead of getName()
String name() { return name;}
is it any option to configure mapstruct to use my naming strategy
In order to use different naming convention for getters a custom AccessorNamingStrategy should be implemented.
The best approach would be to extend the DefaultAccessorNamingStrategy and override the isGetterMethod.
Really important is to make sure that you are really returning something only for getters. Otherwise methods like toString would also be considered as getters
In swift, how is constants implemented?
I read this article, which says
In Swift, constants are generally implemented as (inlined) function calls.
I am not clear of this statement.
Does Swift use a special approach to make constants?
Could anyone explain?
Are you familiar with "getter" and "setter" methods from other languages, such as Java? If a variable is made public in a language like Java, it's exposed to other classes to access directly. In the future, if this variable has to be changed, there's no way to do so without changing all of the other classes dependent upon. With getter/setter methods, dummy implementations can be made that don't do anything besides read/write the value. In the case that a change needs to be made, the implementation of these methods can be changed without effecting the public API of the class.
Swift implements variables with "properties", which are like a backing private variable with public getter/setter methods that are automatically generated. In the future, you can replace a property with a computer property with a special getter/setter implementation, without effecting the public API of the class, just like before. The difference here is that you don't need to write all of the default getters/setters yourself.
According to the JPA 2.1 spec:
It is required that the entity class follow the method signature
conventions for JavaBeans read/write properties
(as defined by the JavaBeans Introspector class)
for persistent properties when property access is used.
In this case, for every persistent property property of type T
of the entity, there is a getter method, getProperty,
and setter method setProperty.
Does this imply that the methods must always be named getProperty
and setProperty
(per the design pattern "convention" in ยง8.3.1 of JavaBeans spec 1.0.1,
"[i]f we don't find explicit BeanInfo on a class");
or could a BeanInfo class be provided to direct the JPA implementation
to a different method
(per the full description of the Introspector class in that spec)?
Although I'm also curious about how Hibernate or other JPA implementations
implement this,
I'm instead really asking what implementation the JPA spec requires.
The methods MUST be named as per the Java Beans contract ... getXXX (or isXXX), setXXX. There is no BeanInfo hook used by any JPA implementation I know of
In my application I have few classes with package-protected methods and JavaDoc associated. I have then some other classes in same package with public methods -- in a few situations the public method is nothing more than a "proxy" for the package-protected method -- for these kinds of situation I would love to "inherit" the JavaDoc from the pp method but I don't know how to do
#inheritDoc works for inheritance situations
#see and #link creates a pointer to a class/method documentation
I would like to "copy" the documentation, not to create a link to the other's method doc.
I've been looking for this kind of annotation but I did not find it.
Any idea?
btw: using NetBeans if I create an interface and implement it in a class, even though I did not annotate the class methods with #inheritDoc I can see the interface documentation when using the class methods -- still wondering why!
Thanks,
Carlo
Per the JavaDocs documentation, this is only possible in three cases:-
When a method in a class overrides a method in a superclass
When a method in an interface overrides a method in a superinterface
When a method in a class implements a method in an interface
Given that you're not overriding a method, it seems it's not possible.
See here: Automatic re-use of method comments
Groovy automatically generates getters and setters, so e.g. when I type:
int someField
I get the field + getter + setter. Now I want to put an annotation on the setter (e.g. #Requires/Ensures from GContracts):
#Ensures({someField >= 0 && someField <= 100})
int someField
And then I get error: Annotation groovy.lang.GrUnit is not allowed on element FIELD - GrUnit and GContracts recognize annotations on methods only. The workaround for this is coding getter explicitly:
#Requires({...})
void setSomeField(int newValue) { ... }
Is there a better solution for this? In Scala there is an elegant solution for this: http://www.scala-lang.org/api/current/scala/annotation/target/package.html
Is there something like that in Groovy? Or alternatively: maybe some workaround for GContracts to allow such annotations?
There are 9 compile phases in the Groovy compiler. The getters and setters are generated very late in the compilation phases, and they are generated after GContracts runs.
If you want to have your code appear as if generated getters/setters are annotated then you'll have to generate the getter/setter pairs yourself and annotate them. Specifically, add two new FieldNodes to the ClassNode (as long as they don't already exist). A field node is an AnnotatedNode, so you can add whatever annotations you want. As long as you do this in a phase before GContracts runs, then GContracts should never know the different.
That said, this sounds like a GContracts feature request.
As you've noted, GContracts does not provide field annotations (current version: 1.2.4). It even does not execute AST transformations on synthetic (generated) methods which might have been added before GContracts runs.
In a nutshell: an easy workaround is to add a custom setter method.
On the other hand, if you would annotate a class with #Invariant holding a class invariant, it would pre-generate setter methods for all properties to check the class invariant before and after execution of the setter method.
That being said, it might be worth to think about including #Requires and #Ensures in that process - i created an issue: http://gcontracts.lighthouseapp.com/projects/71511-gcontracts-core/tickets/32