Názory k článku
Ruby a unicode: co přinese chystané Ruby 1.9?

vaše problémy bych chtěl mít :)

Jsem jediný, komu se zdá, že držet string s informací o kódování je zbytečně složité? Nebylo by lepší pracovat interně v Unicode (kódování dle preferencí autora), a vše do něj převádět?

Japonci nemaju radi Unicode a specialne UTF-8. Stringy v UTF-8/16/32 zaberaju viac pamate ako Shift-JIS & co., takze sa im ani necudujem.

Má to ale dnes ještě reálný význam, nebo je to bezvýznamná optimalizace? Dá se u (J)Ruby aplikace předpokládat, že bude šetřit každý bajtík?

Japonci nemají rádi Shift-JIS & co., protože uprostřed streamu ani nepoznáte, jestli jste na začátku znaku, nebo ne. Takže 'A' může být prosté A, nebo kus nějakého japonského znaku.

Japonci také nemají rádi UTF-16. Z důvodu výše popsaných zkušeností se jim vůbec nelíbí myšlenka rozšiřování Unicode nad 16 bitů. Ani nevím, jestli se japonské verze Windows dodávají se zapnutou podporou Surrogate Pairs.

Třeba Japonci nechtějí v první řadě roundtripy...přinejmenším jsem je slyšel nadávat, že nejsou bezztrátové... :o)

V Linuux se round tripům nelze vyhnout. Například Qt používá UTF-16, kdežto glibc používá UTF-8 a omezeně i UTF-32. Efektivně se překládá všechno pořád dokola mezi jednotlivými prezentacemi Unicode.

Japonci to ale řešit nemusí. Znaky z Shift-JIS jsou podmnožinou Unicode (viz http://www.microsoft.com/globaldev/reference/dbcs/932.mspx), a Japonci dnes používají Windows. Windows jedou komplet v UTF-16 (Win32, .NET, aplikace). Shift-JIS se používá stejně, jako u nás ANSI 1250 - tedy pro importy starých věcí, a v pár prehistorických aplikacích.

Například Qt používá UTF-16, kdežto glibc používá UTF-8 a omezeně i UTF-32.

To ale nejsou znakové sady.

Japonci to ale řešit nemusí. Znaky z Shift-JIS jsou podmnožinou Unicode (viz http://www.microsoft.com/globaldev/reference/dbcs/932.mspx), a Japonci dnes používají Windows. Windows jedou komplet v UTF-16 (Win32, .NET, aplikace). Shift-JIS se používá stejně, jako u nás ANSI 1250 - tedy pro importy starých věcí, a v pár prehistorických aplikacích.

Děláš si srandu? "Japonci dnes používají Windows"? Víš, jaký je absolutně nejrozšířenější OS v Japonsku (co do počtu instalací) a jakou znakovou sadu a kódování používá? Ne, Windows to opravdu nejsou, a Microsoft proti tomu systému bojuje někdy od roku 1989, ale zatím se mu to nepovedlo.

Já měl co do činění jen s mezinárodními firmami (byť třeba pocházejícími z Japonska), a ty jedou Windows.

To si myslí hodně lidí. Nedávno se tady na toto téma docela obsáhle diskutovalo.

Taky si myslím, že tohle řešení je poněkud, no poněkud - zkrátka ne moc dobré. Není nad to držet to uvnitř v rozumném Unicode formátu. Tento recept Ruby - vyřešíme to 50x složitěji, než je to potřeba, je poněkud no poněkud nic moc. Ale uznávám, že fungovat to bude, ale o eleganci a efektivitě se tedy rozhodně mluvit nedá.

"...50x složitěji, než je to potřeba..."

Jste si jist, že kdyby si mysleli, že s Unicode jako jediným interním formátem by fungovalo všechno, co potřebují, že by to neudělali?

Funguje tak Win32, Qt, .NET, Java... Myslíte, že kdyby to nešlo, tak by to tak udělali?

Ne, nefunguje. Nefungují roundtripy s kódováními, která nejsou podmnožinami Unicode. To by pochopila dokonce i bulharská striptérka.

A vy znáte nějaké kódování, které popisuje znaky, jež nejsou podmnožinou Unicode? Já ne. A když takové kódování najdete, jste si opravdu jistý, že ho chcete podporovat? ;)

Ano, znám. A ano, jeho uživatelé ho podporovat chtějí.

Kde vás sebrali? Na otázku "kolik je hodin" také odpovídáte "vím"?

Jaké znáte kódování, které není podmnožinou Unicode? Prosím o lepší odpověď, než "jedno takové je". Kdo ho používá?

http://en.wikipedia.org/wiki/TRON_(encoding) ?

Historické ekvivalenty stávajících znaků? To snad řeší změna fontu, ne? Neměly by se do unicode narvat zvláštní kódy pro Times New Roman a Helveticu?

obavam se to neni tak jednoduche... analogie: preklad Bible Kralicke do moderni cestiny take neni mozny pouhym jejim vytistenim jinym fontem...

Překlad Bible Kralické mám doma a je vytištěný normálním fontem a obsahuje výhradně písmena české abecedy. Jestliže máš konkrétní vysvětlení, proč nelze ty znaky prostě nahradit novými a obalit je tagem <dynastieming>, budu rád. Vycházel jsem z informací, které byly napsané v té Wikipedii, na kterou odkazoval Rejpal. Tam psali, že se mimo jiné jedná o ekvivalenty dnešních znaků (stejná sémantika, jiný tvar).

myslim ze ten stub ve wiki je zavadejici... ty archaicka, stara nebo alternativni verze znaku ma i posunutou semantiku.... s fonty to nejde take proto, ze u kazdeho znaku existuje jiny pocet historicky variant z jinych obdobi (nejde tedy treba udelat font pro "kazdou dynastii")...

v principu jde o rozpor toho, co znamena "psat" u nas a u nich.

Jednak mi přijde problém poněkud teoretický (jaký má TRON obchodní potenciál?), a potom OpenType umožňuje pro jeden znak více alternativních reprezentací. Viz třeba zde (v latince): http://www.typophile.com/node/8122

jak tedy ruby provádí převod znakových sad, když pro ně nemá žádný "společný jazyk" - to má pro každou dvojci sad překladovou tabulku ?

To jsou problemy.. vzdy, kdyz prectu nejaky clanek o Ruby, jsem rad, ze pouzivam Python. (ne ze bych chtel rozjidet flame), muj osobni strucny nazor na vec jmenem Ruby.

+1, C#

Ač se mi v mnoha věcech líbí víc Ruby, musím se zastat i Pythonu:

2) __str__ není vlastně nic jiného, než #to_s.

4) Ale má, sice trošku podivně, ale má: a ? b : c => c if a else b

5) Jo, tak to se líbí i mým kolegům pythonistům. :-) Vůbec by bylo skvělé, kdyby třeba PyPy mohl jednou podporovat alternativní knihovnu, tu bych si _velice_ rád udělal podle sebe. ;-)

Tak tak, od 2.5... Mno, mne prijde, ze jediny opravdu konzistentni objektovy system je CLOS, ale ja jsem divnej. ;-)

Ad 1. Misto uzaveru ma Python proste funkce. Jde zkratka o dve moznosti jak implementovat tutez vec, pricemz obe moznosti maji stejnou silu. Podobne je to i s Ruby continuations vs. Python coroutines.

Ad 2. Ve skutecnosti tam byly objekty od zacatku. Akorat Python nebyl planovany jako ciste objektovy, a to ma sve vyhody (ja napriklad obvykle programuji pouze proceduralne, je to casto rychlejsi). O psani self lze vest spory, ale tezko najdete lepsi (a citelnejsi) reseni. __iter__, __str__ apod. neni hack, ale standardni konvence metod, kterym odpovida nejaka operace v syntaxi jazyka (viz tez odpoved na bod 3).

Ad 3. Muzete to chapat tak, ze len(), str() apod. jsou jen dalsi operatory (podobne +, -, <, ...). Akorat se nahodou pisou stejne jako funkce.

Ad 5. To je ponekud nekonkretni namitka (reflection muze znamenat mnoho vlastnosti jazyka). Ma Ruby metatridy nebo dekoratory?

1) Funkce nejsou totéž co uzávěry, a uzávěry nejsou totéž, co anonymní funkce. A Python má všechny tři. Budiž mu to připočteno k dobru (přestože bindingy v obklopujícím bloku jsou neměnné, ale to stejně zas až tolik nevadí, a navíc, jestli to chápu správně, se to změní s příchodem klíčového slova nonlocal).

2) Procedurálně programujete tak jako tak. Neprocedurálně byste programoval v Prologu s využitím predikátové logiky nebo v SQL. Osobně nevidím problém v tom, že člověk má možnost použít jak funkci, tak i přímo implementující metodu, jelikož funguje oboje, ale spíš v tom, že to přispívá k celkovému "bordelu". Pokud jde o implicitní self, rubí model mi rozhodně nepřijde špatný, ale na pythoní se dá zvyknout celkem bez problémů. :-) To zvyknutí mi usnadňuje značná podoba Pythonu a Lispu (resp. ten CLOSový feel z toho, že příjemce zprávy je parametr funkce, byť v případě Pythonu stále ještě ptrivilegovaný).

5) Jde o to, že Ruby má (dle soudu mnoha lidí, a nejen rubistů :-)) velmi pěkně ošetřené možnosti programového vrtání se v objektech a třídách. Ne že by Python tohle postrádal, to si samozřejmě také nemůže dovolit, jen je to podivně rozházené všude možně po standardní knihovně. Tohle Ruby podědilo ze Smalltalku, který by bez toho ani nefungoval, protože už třicet let mění za chodu sám sebe, aniž by kdy byl jakožto 24/7 program ukončen. :-))) Já to vidím tak, že Ruby reflexi v podstatě bezpracně zdědilo ze Smalltalku již vyřešenou a tak působí mírně konzistentnějším dojmem - však se podívejte sám do dokumentace, třeba na instanční a třídní metody třídy Class. Otázku na metatřídy si jistě zodpovíte sám, když Vám položím protiotázku: Objektový programovací jazyk, jehož třídy mají prvotřídní status, metatřídy mít může nebo musí?