Closed lsong98sh closed 5 years ago
I don't think the language is capable of supporting that, Lombok tricks or no. Sure as hell would be suprising.
As far as ORM mapping is concerned, I suggest looking at '@Embedded' and '@Embeddable' hibernate annotations on classes/class fields instead. Using inheritance for this is an antipattern, for a number of reasons.
Op za 12 jan. 2019 04:10 schreef lsong98sh <notifications@github.com:
Very usefull in ORM mapping. eg.
//fragement code for version @Getter @Setter public class VersionFeature { @Version private int version }
//fragment code for document @Getter @Setter public class DocumentFeature { @Column private String title; @Column private String subject; }
//fragment code for timestamp @Getter @Setter public class TimestampFeature { @Column private Date createTime; @Column private Date updateTime; }
//MyDocumentModel combines the above three fragment codes @Combine({TimestampFeature.class,DocumentFeature.class, VersionFeature.class}) @Getter @Setter public class MyDocumentModel { @Id private int id; @Column private String keywords; }
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rzwitserloot/lombok/issues/2015, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKCRY-K5Ejrc82scIjbBZUHmvnz-mlxks5vCVJDgaJpZM4Z8dT_ .
The proposal reminds me of type unions in C.
Seems to me that Lombok would have to do lots of work to make this a reality. I imagine it would replace all output instances of MyDocumentModel
with a generated class MyDocumentModelImpl
used at runtime which actually has all of the fields / methods from the combined classes.
The IDE plugins would need to pretend that everywhere it sees MyDocumentModel
that it is actually using MyDocumentModelImpl
-- but MyDocumentModelImpl
would never be explicitly exposed to the programmer as a class. It's magic! ✨
I don't think that variables of type MyDocumentModel
would be able to be cast to type VersionFeature
, DocumentFeature
or TimestampFeature
at runtime -- unless Lombok also created an interface for each of these classes. It is not clear that the OP asked for this, but of course, Java does not support multiple inheritance of classes.
Lombok would also need to worry about field collisions and refuse to compile input like this:
public class A {
int a;
}
public class B {
int a;
}
@Combine({A.class, B.class})
public class C {
/* would contain two instances of int a... */
}
In the above, would CImpl
contain two instances of a, or just one instance which is available via the interfaces A
and B
?
Honestly, this sounds like a terrible idea.
On Sat, Jan 12, 2019 at 6:15 PM K. Alex Mills notifications@github.com wrote:
The proposal reminds me of type unions in C.
Seems to me that Lombok would have to do lots of work to make this a reality. I imagine it would replace all output instances of MyDocumentModel with a generated class MyDocumentModelImpl used at runtime which actually has all of the fields / methods from the combined classes.
The IDE plugins would need to pretend that everywhere it sees MyDocumentModel that it is actually using MyDocumentModelImpl -- but MyDocumentModelImpl would never be explicitly exposed to the programmer as a class. It's magic! ✨
I don't think that variables of type MyDocumentModel would be able to be cast to type VersionFeature, DocumentFeature or TimestampFeature at runtime -- unless Lombok also created an interface for each of these classes. It is not clear that the OP asked for this, but of course, Java does not support multiple inheritance of classes.
Lombok would also need to worry about field collisions and refuse to compile input like this:
public class A {
int a;
}
public class B {
int a;
}
@Combine({A.class, B.class})
public class C {
/ would contain two instances of int a... /
}
In the above, would CImpl contain two instances of a, or just one instance which is available via the interfaces A and B?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rzwitserloot/lombok/issues/2015#issuecomment-453764487, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKCRWB9w6DNbh8bX0taxTXgy8HckvpQks5vChg9gaJpZM4Z8dT_ .
-- "Don't only practice your art, but force your way into it's secrets, for it and knowledge can raise men to the divine." -- Ludwig von Beethoven
I agree. Even if it would be possible (it is not because it requires resolution) this would introduce a bunch of possible problems. Such a feature is unmaintainable.
I don't think the language is capable of supporting that, Lombok tricks or no. Sure as hell would be suprising. As far as ORM mapping is concerned, I suggest looking at '@Embedded' and '@Embeddable' hibernate annotations on classes/class fields instead. Using inheritance for this is an antipattern, for a number of reasons. Op za 12 jan. 2019 04:10 schreef lsong98sh <notifications@github.com: … Very usefull in ORM mapping. eg. //fragement code for version @getter @Setter public class VersionFeature { @Version private int version } //fragment code for document @getter @Setter public class DocumentFeature { @column private String title; @column private String subject; } //fragment code for timestamp @getter @Setter public class TimestampFeature { @column private Date createTime; @column private Date updateTime; } //MyDocumentModel combines the above three fragment codes @combine({TimestampFeature.class,DocumentFeature.class, VersionFeature.class}) @getter @Setter public class MyDocumentModel { @id private int id; @column private String keywords; } — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2015>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKCRY-K5Ejrc82scIjbBZUHmvnz-mlxks5vCVJDgaJpZM4Z8dT_ .
thanks!
1) Not possible without resolution, which we don't have 2) Probably a bad idea
I'm spoiled by Typescript. Not sure why people think this is a "bad idea", it'd be a great feature for Lombok, if it were possible in Java.
Very usefull in ORM mapping. eg.