Po wideokonferencji z Matzem

Jarosław Zabiełło — Thu, 21 Feb 2008 01:08:00 +0100

Zapowiadana wcześniej wideokonferencja z twórcą języka Ruby, została dobrze przygotowana przez Google. Obraz był wyświetlany na dużym ekranie, i co ważniejsze można było zadawać pytania prelegentowi i udało mi się nawet dwa zadać. :)

Prawdę mówiąc oczekiwałem że Matz powie coś nowego. Nic takiego nie było. Mam wrażenie że nawet slajdy jakie były wyświetlane gdzieś już wcześniej widziałem. Moim zdaniem, Matz mówi tak słabo po angielsku, że powinien mówić w swoim języku, po japońsku, i korzystać z tłumacza. Nie sądzę że byłoby wolniej, a nie trzeba by było też powtarzać po kilka razy tego samego pytania.

Zapytałem się go, czy istnieje jakaś oficjalna specyfikacja języka Ruby (lub coś podobnego do pythonowej publicznej listy proponowanych ulepszeń). Brak jednego i drugiego powoduje, że jest pewne zamieszanie co do składni jaka ma wejść do Rubiego 2.0. Tak naprawdę to nikt nie wie w jakim kierunku ta składnia podąża. Np. nie wiadomo czy wcześniej prezentowane przez Matza slajdy to tylko takie luźne myśli, czy też jakieś poważne propozycje. Nie wiadomo też czy cokolwiek z takich “pomysłów” jest dyskutowane w jakimś szerszym gronie poza wąską grupą japońskich samurajów (rozmawiających oczywiście tylko po japońsku).

Matz powiedział że jakaś specyfikacja języka jest tworzona przez grupę tworzącą projekt Rubiniusa i że jest z nimi w kontakcie. Widzę, że Matz zaczyna się z kimś liczyć. To bardzo dobrze. Bo Ruby nie jest taki całkiem młody (jest w tym samym wieku co Java i tylko rok młodszy od Pythona) i już dawno przestał być tylko prywatnym językiem Matza do zabawy.

Zapytałem się Matza też o kwestię składni tzw. named parameters w Rubim. Czy już jest jakaś ustalona składnia i dlaczego po prostu nie skopiuje dobrego i przejrzystego rozwiązania jakie występuje od dawna w Pythonie? Dla tych co nie znają Pythona, przypominam, że chodzi o wygodne wywoływanie funkcji z parametrami występującymi w dowolnej kolejności. Najlepiej zobaczyć to na przykładzie.

def test(a, b, c='C', d='D', *args, **kwargs):
  print a, b, c, d, args, kwargs
test(1, 2)  # => 1 2 C D () {}
test(1, 2, d=3) # => 1 2 C 3 () {}
test(1, 2, 3, 4, 4, 5, 6, 7) # => 1 2 3 4 (4, 5, 6, 7) {}
test(1, 2, d='DE', foo='blah') # => 1 2 C DE () {'foo': 'blah'}

Parametry a i b są obligatoryjne, c i d posiadają domyślne wartości. *args to lista dowolnych parametrów (można dzięki temu wywoływać funkcję z dowolnie wielką liczbą parametrów). Zaś **kwargs to słownik pozwalający na dodanie dowolnej ilości kolejnych named parameters. W Pythonie jest to dosyć czytelne i łatwe do zrozumienia.

W Ruby sytuacja wygląda trochę inaczej. Z jednej strony mamy duże ulepszenie w stos. do Pythona w postaci możliwości wysyłania bloków kodu do metody. Z drugiej strony, nie mam w ogóle możliwości wywołania parametrów w dowolnej kolejności lub wywołania tylko niektórych z nich, resztę zostawiając wartościom domyślnym.

def test(a, b, c='C', d='D', *args, &block)
  print "#{a.inspect} #{b.inspect} #{c.inspect} " 
  puts #{d.inspect} #{args.inspect} #{block.inspect}"
end

W Ruby nie ma jak wywołać test(1,2,d=3). Takie wygodne pominięcie na liście parametru c (bo ma domyślną wartość) i tylko tych parametrów jakie nam pasuje możliwe jest tylko w Pythonie. W Ruby aby zmienić parametr d trzeba wywołać też parametr c, czyli w tym wypadku test(1,2,'C',3). To jest bardzo niewygodne i powszechnie stosowanym trickiem na pominięcie tego ograniczenia jest przekazywanie hasza oraz opuszczanie klamer, które w Ruby są nieobowiązkowe. Zatem dla

def test2(x, opts={})
  puts "#{x.inspect} #{opts.inspect}"
end
test2(1, :d=>4) # => 1 {:d=>4}
test2(1, {:d=>4, :c=>'C'}) # => 1 {:d=>4, :c=>"C"}
# to samo bez nawiasów i klamer:
test2 1, :d=>4, :c=>'C' # => 1 {:d=>4, :c=>"C"}

Pozornie uzyskuje się to samo. Faktycznie jest to tylko “dirty hack” i odpowiednik pythonowej konstrukcji

def test2(x, **opts):
    print x, opts
test2(1, d=4, c='C') # => 1 {'c': 'C', 'd': 4}

Po pierwsze, tym sposobem można do metody przekazać dowolny hasz. Nie ma kontroli na poziomie deklaracji metody, trzeba samemu ją sobie dodatkowo zaimplementować. Np. tak:

def params_check(*args)
  x = args[0].keys - args[1..-1]
  raise "Forbiden params: #{forbiden.inspect}" unless x.empty?
end

def fun(x, opt={})
  params_check opt, :c, :d
  puts "#{x.inspect} #{opt.inspect}"
end

fun(1, :c=>'CE') 
# => 1 {:c=>"CE"}

fun(1, :c=>'C', :d=>4) 
# => 1 {:d=>4, :c=>"C"}

fun(1, :c=>'C', :d=>4, :foo => 'bar', 'hello' => 'world')
# => RuntimeError: Forbiden params: [:foo, "hello"]

Po drugie, w wypadku przekazywania dodatkowego hasza, pierwszy musi posiadać klamry, bo inaczej nie ma możliwości rozróżnienia które dane mają wejść do pierwszego, a które do drugiego hasza.

Ale wracając do tego co odpowiedział Matz. Przyznał wprost, że te named parameters jakie miałyby wejść do Ruby 2.0 są tak naprawdę zwykłym… haszem! (zobacz ten slajd z wcześniejszej prezentacji Matza)

def fun(x, c : 'C', d : 4)
  # ...
end

co naprawdę znaczy tyle co

def fun(x, {c : 'C', d : 4})
  # ...
end

Taka innowacja nie jest w zasadzie żadną innowacją, ale sprowadza nas z powrotem do tego co już jest. Jeśli zaś jedyna zmiana jaka tu ma miejsce dotyczy tylko zastąpienia znaków => jednym znakiem dwukropka (tak jak w Pythonie nawiasem mówiąc) to albo ja tu czegoś nie rozumiem, albo to w ogóle jest bez sensu.

Jarosław Zabiełło - BLOG: Tag konferencja

Po wideokonferencji z Matzem