On Thu, Jun 6, 2019 at 1:51 PM Brian Goetz wrote:
library authors suffer a familiar problem: if @Foo is meta-annotated
> with a target kind of RECORD_COMPONENT, then that means it must have
> been compiled against a Java 14+ JDK, which means that the resulting
> classes are dependent on JDK 14+,
On Jun 13, 2019, at 9:46 AM, Brian Goetz wrote:
>
> The benefit of this (compared to B) is transparency: you get what is present
> in the source file.
That's very good.
> The downside is that if you explicitly declare a member, you have to
> explicitly replicate its annotations, and it's easy
There's a sub-option of B that has been suggested, call it B-, which we
can also consider: only push down annotations from record components
into _implicit_ declarations of mandated members, rather than all
declarations (implicit or explicit.)
The benefit of this (compared to B) is transparenc
On Jun 6, 2019, at 1:48 PM, Brian Goetz wrote:
> …
> But, I’m not particularly compelled by this — I think the strategy we took
> for enums is mostly good enough. So I’m voting for pure B.
Yes, I track with your reasoning. Pure B is perfectly
fine as wherever there is a mandated translation st
Recall that some time ago, we were discussing some different directions
for how to handle annotations on record components.
Approach A: Record components are a new kind of annotation target
location; if an annotation is meta-annotated with this target kind, it
can be applied to record componen
> But, that still leaves the question of whether the desugaring should, or
> should not be, transparent to annotations. My sense is that pushing
> annotations down to fields, ctor params, and accessors _seems_ friendly, but
> also opens a number of uncomfortable questions.
Also, we’ve bee
The benefit of default.something is that it can be composed
with ad hoc code, to add assertions, short-circuits, etc.
An empty body notation means you cannot cooperate
meaningfully with the default mechanism.
On Mar 9, 2019, at 6:08 AM, Brian Goetz wrote:
>
> An alternate is to allow the body to
> De: "Brian Goetz"
> À: "Kevin Bourrillion"
> Cc: "amber-spec-experts"
> Envoyé: Mardi 19 Mars 2019 00:25:58
> Objet: Re: Records and annotations
>>> - Should we treat the cases where @A has a target of RECORD_COMPONENT,
>>> sepa
- Should we treat the cases where @A has a target of
RECORD_COMPONENT, separately from the cases where it does not,
such as, only push the annotation down to members when the target
does not include RECORD_COMPONENT? That is, is the desire to push
down annotations based on
On Sat, Mar 9, 2019 at 4:47 AM Brian Goetz wrote:
This came up before, but we didn’t reach a conclusion.
>
> A record component is more than just the lower-level members (fields,
> accessors, ctor params) it gets desugared too. So it seems reasonable that
> it be considered an annotatable progra
An alternate is to allow the body to be left off entirely:
record R(int x, int y) {
@MyAnnotation
public boolean equals(Object o);
}
> On Mar 9, 2019, at 1:57 PM, Brian Goetz wrote:
>
> This raises a related question, which is: what if the author likes the
> def
This raises a related question, which is: what if the author likes the default
implementation, but wants to add more annotations (or Javadoc)?
Currently, the story is decent for constructors; declaring an empty `Foo { }`
constructor recreates the default behavior. There is no equivalent for
This came up before, but we didn’t reach a conclusion.
A record component is more than just the lower-level members (fields,
accessors, ctor params) it gets desugared too. So it seems reasonable that it
be considered an annotatable program element, and that reflection expose
directly the ann
13 matches
Mail list logo
