Open TharmiganK opened 2 months ago
The related spec section is https://ballerina.io/spec/lang/master/#section_8.3.2
According to the spec this annotation should be visible
The static type S for the constructed service object is specified by the type-descriptor if present
IMO, the current behaviour is correct.
The static type S for the constructed service object is specified by the type-descriptor if present, and otherwise is the union of a type inferred from each expression in the expression list as follows. Each expression in the expression-list must have a type Listener<T,A>|E where T is a subtype of service object {}, A is a subtype of string[]|string|() and E is a subtype of error; the inferred type is T. The object-constructor-block has the same semantics as in an object-constructor-expr with a service qualifier and a type-reference that refers to S. If the service-decl includes isolated, then it is equivalent to an object-constructor-expr with an isolated qualifier as well as a service qualifier.
The annotations applying to the object-constructor-expr and its members are evaluated when the object-constructor-expr is evaluated. This means that every object resulting from the evaluation of an object-constructor-expr has its own type descriptor.
If there is a type-reference, then the referenced type is included in the object's type in the same was as an object-type-inclusion, and the type-ids of the constructed object are type-ids of the referenced type. If there is no type-reference, then the applicable contextually expected type T, if any, must be definite, and the type-ids of the constructed object are the type-ids, if any, induced by T.
Static type for the constructor and inherent type of the constructed object aren't the same. The static type is just the contextually-expected type for the constructor. The annotations come from the constructor, not the static type.
The actual object constructor can have the same annotations as the expected type, but with different values.
Since we don't have implementation inheritance, a method will always be implemented in an object constructor or a class, with which we can then include annotations. If you need SocialMedia
's annotations, you should be able to get to them via the implicit type inclusion of SocialMedia
in the constructed object.
May be different for fields though - https://github.com/ballerina-platform/ballerina-lang/issues/38535.
@MaryamZi Are you suggesting to get the annotation values of the SocialMedia
type and combine those with the service constructor annotations? If yes, since we are not supporting inheritance doing this also not correct right?
@MaryamZi Are you suggesting to get the annotation values of the
SocialMedia
type and combine those with the service constructor annotations? If yes, since we are not supporting inheritance doing this also not correct right?
Not suggesting combining per se, just suggesting how to access the annotations, it's up to the user to decide how/when to access what.
Generally, I'd expect relying on the annotations from the constructor.
Description
I have defined a service object type and added serveral annotations to the type as well as the resource functions. Those annotations are not visible in runtime when I access the service object provided by the service declaration approach.
Steps to Reproduce
Sample Ballerina code:
Affected Version(s)
Ballerina SwanLake Update 9 (2201.9.0)
OS, DB, other environment details and versions
No response
Related area
-> Compilation
Related issue(s) (optional)
No response
Suggested label(s) (optional)
No response
Suggested assignee(s) (optional)
No response