Request annotation for instance methods that return "this" or some instance of the type of "this"

[cbfiddle]

I'm requesting an annotation, I'll call it @ThisType, that can be attached to the return type of an instance method declared to return the type of the class containing the method definition.

For example:

abstract class Animal {
    public abstract @ThisType Animal copy();
}

I intend this annotation to have this effect on the IDE:
If an overriding method is created in a subclass, the return type is set to the subclass type.

For example, if I create a subclass Dog and use the Override Methods... action to override this method, the method that is created is:

@Override
public @ThisType Dog copy() {
    return null;
}

It would also be useful to have a quick way to override all of the @ThisType methods.

This feature would make implementing fluent APIs with subclasses a bit easier.

[amaembo]

This could be expressed in a more verbose way, like @Contract("-> this"), though override methods refactoring doesn't react on this annotation (currently, it's used in some static analysis inspections).

[cbfiddle]

Yes, using @contract certainly is more verbose. Probably, @contract could be used for almost anything. That does not seem sufficient to reject a proposal. Would you prefer @contract(“-> !null”) to @NotNull? My thought in using a new annotation is that someday Java may support “thistype” as a type, and it would make the conversion simple. Also, does @contract also support “this type, but not necessarily this”? I don’t see that it does.

…

On May 16, 2021, at 6:44 PM, Tagir Valeev ***@***.***> wrote: This could be expressed in a more verbose way, like @contract("-> this"), though override methods refactoring doesn't react on this annotation (currently, it's used in some static analysis inspections). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSSJGNHGFPM5EQIK3ZAY5LTOBYHXANCNFSM447LWUGQ>.

[chashnikov]

I also think that such annotation will be useful. Currently we sometimes add a special generic parameter as a workaround (abstact class Animal<Self extends Animal<Self>>), see ObjectPattern.java from IntelliJ sources, for example, but such approach has many evident drawbacks.

[chashnikov]

There was a feature request (JDK-6479372) about supporting this in Java language, not sure if this is included into some JEP.

[BasLeijdekkers]

Note that using a @ThisType annotation as an alternative to the special generic parameter, will require explicit overriding of all @ThisType methods in all non-anonymous subclasses.

[chashnikov]

Note that using a @ThisType annotation as an alternative to the special generic parameter, will require explicit overriding of all @ThisType methods in all non-anonymous subclasses.

@BasLeijdekkers the generic parameter is also needed to be explicitly specified in subclasses, but what's much worse, you also need to explicitly specify it (at least as ?) everywhere the base class is used.

[chashnikov]

BTW if we support this annotation in IDEA, we may automatically add cast to actual instance type when a method returning Self is completed, and also fold that cast in the editor. This way it won't be necessary to explicitly override such methods in subclasses.

[amaembo]

Probably, @contract could be used for almost anything.

Not even close.

That does not seem sufficient to reject a proposal. Would you prefer @contract(“-> !null”) to @NotNull?

NotNull can be used for types, variables, fields, parameters, while contracts are applicable to methods only. So, @NotNull cannot be completely expressed in terms of contract. In contrast, your suggested annotation applies to method returns only, so it's expressible via contract.

My thought in using a new annotation is that someday Java may support “thistype” as a type, and it would make the conversion simple.

This will unlikely happen in near future and if it happens, converting @Contract("-> this") would be as easy as converting the new annotation.

@chashnikov

for example, but such approach has many evident drawbacks.

Adding an annotation will not change the Java language. In particular, you will still be forced to override all the base class methods with a covariant return type or add casts at the call site. The annotation may simplify code generation (assuming anybody actually will use it) but that's all.

BTW if we support this annotation in IDEA, we may automatically add cast to actual instance type when a method returning Self is completed, and also fold that cast in the editor. This way it won't be necessary to explicitly override such methods in subclasses.

Sounds dirty. Anyway, we already have an annotation for this, so you can implement it if you want :-) If you find it useful we may consider adding a shortcut alias to the existing contract (btw why stopping here? Why not also @Pure for @Contract(pure = true), etc? Let's add more annotations!)

[chashnikov]

@amaembo as far as I understand @Contract("-> this") means that the method returns the same instance it's called on, whereas @ThisType will mean that the method return an object which has the same type as the instance it's called on. So we can annotate methods in builders with @Contract("-> this"), but it isn't correct to use this annotation for copy method from the issue description, because it returns a different instance.

Adding an annotation will not change the Java language.

Surely. However by adding annotations and supporting them in the IDE we sometimes can improve experience for users who write in the Java language, that's one of the purposes of using the IDE instead of a text editor after all. We did such things many times in the past, e.g. we started to automatically add type parameters for constructors call and fold them in the editor long before diamonds were supported in Java. And we folded anonymous classes to look like lambdas in the editor before Java 8 was released.

[cbfiddle]

As @chashnikov <https://github.com/chashnikov> has pointed out, your proposed already-existing alternative only partially satisfies the requested semantics. Unless you are proposing to extend @contract (which is why I said it *could* be used for almost anything), @contract is not a valid alternative. For that reason, this issue should be reopened. Alan

…

On May 17, 2021, at 10:43 PM, Tagir Valeev ***@***.***> wrote: Probably, @contract could be used for almost anything. Not even close. That does not seem sufficient to reject a proposal. Would you prefer @contract(“-> !null”) to @NotNull? NotNull can be used for types, variables, fields, parameters, while contracts are applicable to methods only. So, @NotNull cannot be completely expressed in terms of contract. In contrast, your suggested annotation applies to method returns only, so it's expressible via contract. My thought in using a new annotation is that someday Java may support “thistype” as a type, and it would make the conversion simple. This will unlikely happen in near future and if it happens, converting @contract("-> this") would be as easy as converting the new annotation. @chashnikov <https://github.com/chashnikov> for example, but such approach has many evident drawbacks. Adding an annotation will not change the Java language. In particular, you will still be forced to override all the base class methods with a covariant return type or add casts at the call site. The annotation may simplify code generation (assuming anybody actually will use it) but that's all. BTW if we support this annotation in IDEA, we may automatically add cast to actual instance type when a method returning Self is completed, and also fold that cast in the editor. This way it won't be necessary to explicitly override such methods in subclasses. Sounds dirty. Anyway, we already have an annotation for this, so you can implement it if you want :-) If you find it useful we may consider adding a shortcut alias to the existing contract (btw why stopping here? Why not also @pure for @contract(pure = true), etc? Let's add more annotations!) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSSJGOQFEQ2M6RTAAT52X3TOH5ARANCNFSM447LWUGQ>.