feat: support crud method metadata of spring

[shouwn]

Motivation

• Kotlin JDSL does not support CrudMethodMetadata of Spring Data.

Modifications

• Support @Lock of Spring Data.
• Support @QueryHints of Spring Data.

Closes

• Support CrudMethodMetadata of Spring Data #664

[cj848]

Suggested change

	if (lockMode != null) {
	lockMode?.run {

how about this style?

[shouwn]

I think if is better in this case.

[cj848]

ok. It's a style so it doesn't really matter
However, for null checking, how about !== null (reference comparison) rather than != null?

[shouwn]

How do they differ? What's the difference between the two? I checked with Java compilation and there is no difference between lockMode?.run, if (lockMode != null) and if (lockMode !== null) for null checking.

[cj848]

== is an equals comparison, === is a reference comparison.
However, as far as I know, this is according to the Kotlin language specification and may be the same when converted to Java.
In the case of variable?.run , the run method is an inline method, so we expect the code to be converted to Java code as a result, similar to the if code.

As a result, === conveys a clear intent about which values require reference comparison.

[shouwn]

You're not talking about functionality, you're talking about how to express the code. I think it's not a bad idea to use reference equality to indicate whether the reference of this object is null or not. But if you have to enforce it for the whole project, I don't think so.

Kotlin provides both structural equality and reference equality as ways of checking nullability. You can see this by looking at the code that Kotlin itself uses. They use structural equality in some places and reference equality in others to check the nullability.

==null case
===null case

So I don't want to force people to use === when checking the nullability.

[cj848]

I don't think the part that checks for nullability is relevant. There is no problem doing whatever you want. In addition to ?.run, I think it would be good to discuss the part about checking the enum with ===.
In the case of enums, I think === is more correct because it is a singleton and does not need to be checked with equals(==).

However, looking at kotlin documentation, it does not seem necessary.

I respect your opinion.

[shouwn]

I appreciate your respect.

Regarding enums, I would rather use == than ===. Enums are singletons, but they are also objects. We use structural equality a lot as a way to compare two objects. That's why I think it's better to use == when comparing enums.

For example, suppose you have a method that looks like this:

fun compare(color1: Color, color2: Color): Boolean {
  TODO()
}

How would you compare them? When you use ===, it means that you know that the Color class is implemented as an Enum class.

What would happen if you changed the implementation of the Color class to a Sealed class instead of an Enum class? If you used ===, you would have to change the implementation.

This is because Enum is a way to implement an enumeration, and Kotlin provides Sealed classes as a way to implement an enumeration. That's why I prefer to use === instead of ==.

[cj848]

It's like a difference in perspective. If you change to a sealed class, there is a possibility that the logic will change a lot, and you will definitely have to recheck the automated tests you created, but I don't think there is a need to approach the issue of whether or not to fix the code. However, in the case of null checking inside Kotlin, there is documentation that === or == will be converted automatically, so there is no harm in following your convention unless there are other cases where you need to explicitly check the reference.

And since my review is approved, I think you can merge it when you want.

[progress0407]

Wow... that's amazing. I'm learning.