I’m thinking of adding some Kotlin extensions to the jOOQ library. One interesting thing might be to make use of infix functions, e.g.
infix fun Condition.and(other: Condition): Condition {
return this.and(other);
}
infix fun Condition.or(other: Condition): Condition {
return this.or(other);
}
This would allow for expressions like:
(A eq 1) or ((B eq 2) and (C eq 3))
However, note the need for explicit parentheses around all sorts of expressions, specifically to give and an explicitly higher precedence than or, which is the expected behaviour in most languages (e.g. SQL). I guess I’d rather not use infix functions this way, it would be rather confusing for users.
Is there a way to specify operator precedence for infix functions in Kotlin or are there any plans to support this in the future?
However, overloadable &, |, ^ are on the table: https://youtrack.jetbrains.com/issue/KT-1440
The were present in the most recent community feature survey, but were not quite popular.
Thanks for the pointer. Interesting. I’ll comment directly on there as well.
I suspect that overloading pre-existing operators will mean that precedence is inherited. Yet, when people “rename” && as and, || as or, yet the readable versions do not inherit the expected precedence, things get a bit weird…
Hi @lukas.eder - since this thread is dead or on its last breath I would like to use the opportunity to digress a little.
A really big thanks for considering JOOQ port for Kotlin. Operator overload would have been nice here - but I hope you will still see that Kotlin gives the opportunity for better syntactical representation of JOOQ.
I have done a smallish but complicated project using JOOQ with Kotlin and really want to tell you -
WELL DONE! The learning curve was tiny, the constructs felt as natural as Java permits, all aspects were extremely well thought out; the utilities were easy, assistance and documentation was forthcoming when needed - and best of all - the Kotlin calls to the Java generated code didn’t feel too alien; even multi-tennant with Spring in no time. Your feedback on listening to suggestions is also heartwarming and appreciated.
@Gawie_Kellerman thanks for your nice words. Well, I don’t think we’ll port jOOQ to Kotlin but there’s a low hanging fruit with these inline / infix / operator functions in Kotlin, which work out of the box with existing Java API, which is a really nice Kotlin feature (the same is true with Scala’s implicit functions). Of course, any help in the right direction would be great, too! Perhaps, this doesn’t work for actual operators (which rely on precedence), but it might work with ordinary SQL syntax.
I suspect that overloading &, | and ^ might have been more popular if it had been better explained in the survey what they were supposed to be overloading in the first place.
Whilst it would arguably have been better if Kotlin had implemented the ‘traditional’ bitwise operators (&, |, ^, ~, <<, >>) in the first place, it seems to me that this ship has now sailed and we should therefore concentrate on improving the corresponding infix operators so that they have an assignment form (x and= y, or whatever) and that there is some way of controlling the priority.
It is sometimes forgotten that and, or and xor can also take boolean operands as well as integer operands even though they are rarely used. The only reason I can think of why the first two would be preferred to && and || is because you always wanted the second operand (perhaps a function call) to be evaluated because of some side effect. However, even in C programming, this is considered bad practice nowadays and so they are virtually useless in Kotlin itself.
I could therefore see the sense in the boolean versions of these infix operators being replaced by &, | and ^ as it would break very little code and make these operators available for overloading in DSLs etc. An assignment form would then be no problem and the priority would be what (most of us) would expect
This ship hasn’t sailed; overloading &, | and ^ is still on the table and far more likely to be implemented than the possibility to specify priorities for infix functions or to call them as part of an augmented assignment.
Sorry for reviving this thread, but I couldn’t find anything more recent about this and didn’t want to duplicate it either.
It is a bit sad that even java looks better when handling bytes. What would need to happen in order for this feature to become part of the next Kotlin version?
Also, still on the byte manipulation logic, since we don’t have automatic conversions between the different length integer types I wonder what 0xFF.toByte() does. Is it going to compile as a 8-bit literal or convert a 32-bit one into 8 bits at runtime? That’s a big difference. And if what actually happens is the latter, what would it take to have a way to express byte literals?
Examples:
Current kotlin code (I have to convert byte to int in order to use the unsigned shift to right operator)
decoded[byteIndex] = decoded[byteIndex] or ((decodedValue.toInt() and 0x10) ushr 4).toByte()
I understand the Java version that looks like the latter has lots of implicit Int<=>Byte conversions which we don’t want; here I am imagining/wishing that we have:
All the operators Java has
Byte literals (which java does not have)
Byte & Byte → Byte (already in kotlin.experimental as an infix operator!)
Byte >>> Byte/Short/Int/Long → Byte
…or sillier code:
// Chop off an ending zero, if it exists
return if (decoded.last() == 0x00.toByte()) {
decoded.copyOfRange(0, decoded.size - 1)
} else {
decoded
}
This one, thanks to ByteArray.last and ByteArray.copyOfRange, looks much better in Kotlin than in Java already, but this 0x00.toByte() takes out big part of the fun.
but there’s a low hanging fruit with these inline / infix / operator functions in Kotlin, which work out of the box with existing Java API, which is a really nice Kotlin feature (the same is true with Scala’s implicit functions). Of course, any help in the right direction would be great, too! Perhaps, this doesn’t work for actual operators (which rely on precedence), but it might work with ordinary SQL syntax.