I would like to be able to get a common feature from different annotation types. Is it possible to create sub-classes of the annotations and then get them by the super-class?
This is the way I am doing it at the moment but I would like to be able to get a general super-class of annotation rather than a specific one.
TypeSystem typeSystem = jcas.getTypeSystem();
Type type = typeSystem.getType("com.example.SpecificAnnotation");
AnnotationIndex<Annotation> annotationIndex = jcas.getAnnotationIndex(type);
Annotation annotation = annotationIndex.iterator().next();
String value = annotation.getFeatureValueAsString(type.getFeatureByBaseName("value"));
You can create an annotation type X with the common features. Then you can create additional annotation types which inherit from your type X instead of inheriting from Annotation.
Related
With Java Annotations, is it possible to create a custom annoation that accepts a non-enum argument, like from a instance method?
For example, would this type of thing be possible to do?
#Builder(toBuilder = ENV_UTIL.getProperty("allowToBuilder"))
public class MyPojo {
//add fields here later
}
I am wondering because compiler wont let me do something like this with Lombok. So, does this mean there is a reason for this and it could never work, even on my own custom annotation?
Is there a way in Scala 3 to use derives keyword in combination with opaque type aliases?
It would be nice to have a boilerplate-free way to provide a typeclass instance to a given opaque type alias by automatically rely on the instance of the same type class for the underlying type (if any).
Would be nice to have the possibility of expressing something like
opaque type Id = Int
object Id:
given Show[Id] = Show.intShow
for some hypothetical typeclass Show, as
opaque type Id = Int derives Show
You can see in syntax.md that there is no such construct at the moment.
Also, even if such syntax was available, I'm not sure if this should be the default behavior. The motivation behind using opaque types is to distinguish the new type from the underlying one. Though I get why it would be useful to have, just not as a default.
Maybe something similar to Haskell's deriving via might be a good addition here.
It might be a good candidate for a SIP.
The question popped in my head, what is happening when I define a Swift type alias? What is the mechanism behind it? Until I learned the Automatic Initializer Inheritance chapter from the Swift official document:
If your subclass doesn't define any designated initializer, it automatically inherits all of its superclass designated initializers
And here is my practice code for learning
class Vehicle{
var numberOfWheels = 0
var description: String {
return "\(numberOfWheels) wheel(s)"
}
}
class Auto: Vehicle{}
let VM = Auto()
VM.numberOfWheels
Wow! this works,at least performs, exactly as the Swift type alias. Auto is the alias of the type Vehicle
Question: Am I understand it right? This is the mechanism behind type alias.
Question: Am I understand it right? This is the mechanism behind type alias.
NO, typealises and subclassing (with inheriting all methods and initializers) are different things and based on different semantics and mechanisms.
let v1 = Vehicle()
v1 is Auto //->false
typealias Norimono = Vehicle
v1 is Norimono //->true (with warning "'is' test is always true)
The last result (including the warning you may find) is exactly the same as v1 is Vehicle.
Typealias is literally an alias, it's giving another name for the same type.
One more, you can define typealias of structs or enums, which you cannot define inherited classes (types).
Not really, but if you've never seen object oriented programming they could look somewhat similar, i agree.
Auto is a subclass that extends the original vehicle and could add additional properties and method to the Vehicle even if in that example it doesn't do it.
Auto and Vehicle are not the same thing, a Vehicle is a basic type and and Auto is one of its subtypes, what you can do with a Vehicle you can do with an Auto but not vice-versa.
A typealias is just an alias, a way to give and additional "name" to a pre-existing type, just that. A type and his alias are the same thing.
Annotations in Kotlin can have different use-site targets as explained here: https://kotlinlang.org/docs/reference/annotations.html#annotation-use-site-targets
My question is: When use-site is not explicitly defined, what is the default target when annotating property in a class like in the example below?
class Test {
#SomeAnnotation
var someProperty: String? = null
}
Background
I'm trying Jongo as MongoDB client in Kotlin and have problems annotating id field. Jongo does not map id property correctly when it's annotated like this:
#MongoId #MongoObjectId var id: String? = null
The annotations in question are just meta-annotations for Jackson. However it seems to work when I annotate the property like this, indicating use-site problem:
#field:[MongoId MongoObjectId]
var id: String? = null
I would expect that #field is default use-site, but it seems that it isn't.
The reference says:
If you don’t specify a use-site target, the target is chosen according
to the #Target annotation of the annotation being used. If there are
multiple applicable targets, the first applicable target from the
following list is used:
param (constructor parameter)
property (annotations with this target are not visible to Java)
field
So if your annotation has #Target({ElementType.FIELD}), the annotation in Kotlin will target #field:.
If it has no #Target specified, it may be used on any program element: the #property: target is also applicable and is chosen by default.
I have a little bit of a curve ball for you. Maybe just a design issue...maybe even something as simple as me not understanding Data annotation providers.
Anyway here we go:
I have a class which represents some model data. Let's say it represents a package/box/carton.
It actually represents all of these things so I use the class in several different views. Sometimes I want the attribute of the field Package_Description to be
So that it shows up as Box Number : input box here.
Now if i want it to appear as "Carton Name" my only option would be to sub type it. Or use a separate class to have the annotations for this class. My quandary is that some of the field names are user configurable and therefore I cannot have a static definition!
(By the way i am using third party librarys [Telerik MVC Grid] do display these field names so i cannot change the fact that it's looking at data annotation )
So I just need to know is there a way to add attributes dynamically?
Create an anonymous type on the fly, sub class the original and then add attributes using reflection?
Or what other options are open to me, do I need to somehow implement a different annotation provider?
Attributes are part of the definition of the type. Because of that, you can't modify attributes of existing classes during runtime.
You could create a new type during runtime (not an anonymous type), but I think that's not such a good idea. I'm sure whatever component you're using, it allows you to specify the appearance explicitly.