Ruby pro začátečníky - 7 (metody a třídy) (diskuse)

[Jiří P.]

Pěkné-dík za článek. Vidím, že RUBY je hodně podobný Pythonu, ale Pythoní syntaxe mně osobně sedí víc. Měnit nebudu... ;)

[cezz]

+1, ale nikdy nevies, kedy nebudes mat na vyber

[Janda]

Mohl by mi nekdo (skutecny vyvojar, ktery v tom udelal uz neco poradneho) vysvetlit, k cemu je to Ruby dobry? Jestli je vyhodou tohoto jazyka jeho syntaxe (coz je navic dost subjektivni), tak to se muze jit zahrabat. Programovaci jazyk neni to nejdulezitejsi - mnohem dulezitejsi jsou ty "veci zatim" - jako kvalitni vyvojove prostredi, platforma, na ktere bezi, dostupnost ruznych knihoven apod. Dost bych se divil, jestli se v tomhle smeru muze Ruby rovnat Jave, C# nebo C++. Spis to vypada na dalsi hracku pro stouraly, kteri se zajimaji o vsechno mozne, ale nic skutecneho nikdy nevyvijeli. Zda se, ze uz i Lisp ma v tomhle smeru lepsi zazemi nez Ruby a to je co rict. Ale mozna se pletu...

[Kyosuke]

Chmm. Hele, milej zlatej smug Java weenie, až uděláte pro Javu stejně dobrej XML parser a generátor, jako udělal Oleg Kiselyov, tak se můžeme bavit o dobrých knihovnách. Zatím zůstanu u SXML. U něj se aspoň dá říct, že je integrovaný do jazyka a poskytuje literály pro snippety.

A abych si ještě rejpnul, "věci okolo" se dají změnit/napsat/předělat pořád ještě snáze, než zprasený jazyk. Takže i když mohou být knihovny důležitější, je mnohem větší průser, když zjistím, že se peru s jazykem. Ona totiž knihovna (třeba pokud je v Cčku) je pro vývojáře v první řadě API a na to se dají udělat bindingy snad do čehokoli.

Jinak řečeno, pro Ruby je v podstatě k dispozici totéž, co pro Python nebo pro Perl. A SWIG to ještě o notný kus srovnává. Pokud jde o platformu, není co řešit - stačí ANSI C kompilátor. A pokud jde o vývojové prostředí, jestli mi sáhneš na Emacs, urazím Ti pazoury.

Ale podotýkám, že rubista jsem jen okrajově, velké aplikace v tom asi dělají jiní zdejší. Já už si příliš zvykl na luxusní lispí kompilátory. Jen mi prostě přijde, že jakmile se člověk dostane k opravdu velkým věcem, tak programovací jazyk teprve začne být ta nejdůležitější věc.

[Janda]

Tak to pak jo - uz vic nerikej... Jen tak kdyz jsme v tom rejpani - muzes jmenovat nejaky velky projekty napsany v Ruby (ne nejakej web franty fuky)? Docela by me zajimalo, co uzasnyho se v tom vytvorilo.

[Kyosuke]

nejaky velky projekty napsany v Ruby

Zatím nikdo nic extra velkýho neprásknul, ale už jen ve standardní distribuci Ruby by mělo být ~420000 řádků Ruby. To mi přijde celkem dost. Rails mají momentálně cca. 70000 řádků.

Tedy, mlčky předpokládám, že to je významná metrika, co taky nemusí být vždy pravda. Je taky otázka, jestli existuje jeden velký monolitický projekt, na kterém by se dalo něco takového ukázat. Rubisté už ze své podstaty nesnášejí molochy typu J2EE, takže k tomu asi ani nemají tendence. (Ani mezi pythonisty zřejmě neplatí, že by kvůli Zope každý slintal. ) Pro mě je největším rubím projektem RubyForge.

ne nejakej web franty fuky

[mkoubik]

ad "Přístupové metody". Nepoužívá se na tohle náhodou attr_accessor:? Potom se do tý proměnný dá i zapisovat a nemusí se na to dělat extra metody stylem:

class Pes
  def initialize(jmeno)
    @jmeno = jmeno
  end
  def name
    return #{@jmeno}
  end
  def setName(jmeno)
    @jmeno = jmeno
  end
end

Místo toho se použije

class Pes
  attr_accessor: jmeno
  def initialize(jmeno)
    @jmeno = jmeno
  end
end

[Kyosuke]

Ta dvojtečka je za mezerou, ne před ní.

[botanicus]

Presne tak, protoze to znaci symbol. Casto se pak stava, ze clovek chce napsat vic metod a pak je dvojtecka pred kazdou z nich ... To jen aby nerubysti vedeli ;)

[botanicus]

Ano a BTW netreba vypisovat "#{@jmeno}", kdyz staci "#@jmeno" ;)

[frm]

Objektově orientovaný přístup se snaží ještě více přiblížit strukturu programu lidskému myšlení a vnímání reálného světa. Člověk o okolním světě (většinou) neuvažuje jako o sadě proměnných a procedur, ale jako o objektech. Tento přístup umožňuje nejen o problémech přemýšlet a pojímat je jako reálné věci, ale také objekty z jednotlivých objektů skládat, ba dokonce vlastnosti dědit.

Tento sileny omyl se nestane pravdou, ani kdyz se to bude kopirovat do kazdeho odstavce zde na ABC a jakychkoliv jinych servrech. OOP je jeden z nejvetsich omylu lidstva. Kdo se nyni pta na dukazy pro me tvrzrni, tak at si prohledne clanky na tomto serveru - x-krat v nich jiz zaznelo, ze lide nedokazou OO myslet !!!

[Kyosuke]

Ale no tak. Třeba takový CLOS přece není tak špatný. Nehledě na to, že v kombinaci s funkcionálním přístupem (nedestruktivními aktualizacemi - Alan Kay certified(R) ) je to mocný nástroj.

[botanicus]

Projdi se na cerstvem vzduchu, to bude dobry :)

[JoHnY]

V urcitym rozsahu mas pravdu. Nicmene v globalu je to kravina. Nenasel se zadnej lepsi zpusob, kterej by byl tak snadno spravovatelnej. Pomoci vsech kouzel moderniho OOP jde vytvrit milion radku kodu a pritom se v nich da vyznat.

[Kyosuke]

Hmm, "moderního"...problém je spíš v tom, že to "starší" pojetí OOP je mírně lepší...nebo aspoň to dopadá tak, že lidi cca. od začátku 90. let vidí jen "dědičnost, zapouzdření a polymorfismus" a na základě těchhle blbostí (jen ta třetí věc je nezbytná, ten zbytek je dost překroucený) si řeknou "žádná sláva". Jenže on Kay to formuloval trošku jinak a navíc to vyžaduje slušnou změnu myšlení - docela by mě zajímalo, kolik OOP programátorů cíleně potlačuje změnu stavu objektů na minimum. Zní to funkcionálně? Možná, ale Kay to chtěl právě takhle. "Doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming.". A pak lidi vesele píšou strukturovaně imperativní kód v poloobjektovém jazyku typu Javy a diví se, že se jim abstrakce hroutí. Při troše snahy může dobrý programátor psát dobrý kód v jakémkoli jazyku (ano, i v Perlu ), ale prasata dokážou zprznit cokoliv. A pak takhle nadávají, ačkoliv za jejich problémy OOP ve skutečnosti vůbec nemůže.

[Kyosukeho_svedomi]

At uz to kdokoli chtel jakkoli, tak objekty pochopitelne musi mit svuj stav. To je jako s objekty v realnym svete. Kdyz treba potkam v divocine lva, tak taky nebude jednat jen podle toho jaky mu poslu parametry (jak vypadam), ale i podle toho v jakym je stavu - nenazranej, nazranej, nenazranej a jeste k tomu nasranej, ...