Some features from ruby


#1

I propose to add the next features which exists in the ruby language. I would like to see them in Kotlin. Link to source http://www.fincher.org/tips/Languages/Ruby/

  1. Return last expression

Two equals code blocks:

fun mult(a: Int, b: Int):Int {   return a*b }

fun mult(a: Int, b: Int):Int {   a*b }

2. Multiple return

fun getCostAndMpg():Int,Int {      cost = 30000 // some fancy db calls go here   mpg = 30   return cost,mpg } AltimaCost, AltimaMpg = getCostAndMpg() println("AltimaCost = ${AltimaCost}, AltimaMpg = ${AltimaMpg}")

3. Hashes

val cars = { 'altima' => 'nissan', 'camry' => 'toyota', 'rx7' => 'mazda' }
println(cars['rx7']) => mazda

4. Dinamic hashes

=
{}  # create a new dictionary dict['H'] = 'Hydrogen' #associate the key 'H' to the value 'Hydrogen' dict['He'] = 'Helium' dict['Li'] = 'Lithium'

5. If, while statement at the end

var balance = -10.0
println("Bankrupt") if balance < 0.0

var balance = -10.0
puts “Bankrupt” unless balance > 0.0 //‘unless’ is inverted ‘if’. Maybe add to kotlin too?

var f=2
println (f=f+2) while f < 10


6. to_s is a synonym the “ToString” function

  1. Parallel Assignment(as an extension multiple return)
    var i = 0
    var j = 1

i,j = j,i //swap the values in variables without the use of a temp variable


#2

  1. Return last expression
Partly supported, to me it looks like the code gets messier with this convention

2. Multiple return

We are thinking about it.

3. Hashes

Supported in the form:

val cars = map ("altima" to "nissan", "camry" to "toyota", "rx7" to "mazda") println(cars["altima"])

4. Dynamic hashes

Supported: use a HashMap

5. If, while statement at the end

Looks unncecessary. A close analog can be implemented with library functions

6. to_s is a synonym the "ToString" function

Looks unncecessary, too. One can define a corresponding extension function, though

7. Parallel Assignment(as an extension multiple return)

See 'multiple return'

#3

Thanks for your overview my topic :)


#4

With tuple support [1] does one actually NEED multiple return?  Given that labelled tuples are not yet implemented, what would be a nice addition would be some form of tuple destructuring support:

fun tupleTest() : #(Int,String) {
  return #(1,“Mark”)
}

#(val age, val name) = tupleTest()

println("$name is $age")

The destructuring is a play on what one can already do inside pattern matching with a “when”.  Actually, this could work well with my “let” idea mentioned in another thread.

[1] http://confluence.jetbrains.net/display/Kotlin/Tuples


#5

Tuples seem to be an overkill for what they are used for, so we are strongly considering getting rid of them... In fact, people use only pairs, tuples of other arities are extremely rare.


#6

Looks unncecessary. A close analog can be implemented with library functions

I like this reasoning. This is basically why I stopped looking at Scala some time ago and then was glad when I discovered Kotlin as Kotlin contains many of the good things in Scala. F.ex. in Smalltalk even conditional expressions are part of the library (instance methods of the Closure class) amongst other things. This also has its pros and cons, but it keeps the language concise and coherent.It might be a good idea when Kotlin gets close to 1.0 to take an effort to spread the news. I only found out about Kotlin by pure luck.


#7

Tuples...It's good. I have not read documentations fully yet. Tuple21? Really? How can user will use Tuple21? I think return many values from functions is a  bad ugly code. May be necessary to limit tuple with 5 elements


#8

Thanks for the kind words :)


#9

I believe that even Tuple4 is unnecesary, and Tuple3 is very rarely used.


#10

it seems to be true. In other cases better use a class or array


#11

FYI, Andrey, my assessment of all these features would have been pretty much exactly identical to yours: some useful features in this list and some that are not so much.

Also: I am not surprised to hear that tuples are hardly ever used except for pairs, so definitely a feature that should be up for removal. Just offer a Pair&lt;&gt; class in the libraries and call it a day (and even using pairs is a bit of a smell in my opinion).


#12

Just offer a `Pair<>` class in the libraries and call it a day (and even using pairs is a bit of a smell in my opinion).

Yes, I also thought this way. But then for something like this:

when (tuple) {
  is #(1, 2) -> ...
  is #(val a, 3) -> print(a) // binding a to the first element of the tuple
  !is #(*, 1100) -> ... else -> ...
}
tuples might still be useful. And later for the compulsory actor library (without which no modern language nowadays would be considered complete by anyone ...) tuples may be needed for the Kotlin actor solution to be as elegant as in Scala or Groovy or whatever. Whatever is fine with me, just no case classes please ... ;-)