Vlákno názorů k článku Vykreslení tabulek do terminálu v jazyce Go od Smazaný profil - Vidím tam jednu, ale docela podstatnou, návrhovou vadu....
-
Smazaný profil
Vidím tam jednu, ale docela podstatnou, návrhovou vadu. Uživatel té knihovny musí nejprve poslepovat textový řetězec, do kterého vloží tabulátory (a pokud v původních hodnotách tabulátory byly, tak by je měl nějak escapovat - otázka je jak...), tento textový řetězec předá knihovně a ta ho pak musí rozparsovat. Tzn. je tam nesmyslná serializace a deserializace do nějakého textového pseudo-formátu místo toho, aby se předávaly objekty/struktury.
Ono v těch příkladech to vypadá dobře a jednoduše, ale v praxi se takhle nebudou formátovat konstanty, ale data pocházející z nějakých jiných zdrojů (databáze, výsledky volání nějakých funkcí, nějaké jiné datové struktury atd.). Takže ten převod na text a zpět je tam prostě nadbytečný, ba škodlivý.
Ta knihovna tableprinter uvedená na konci článku, to - zdá se - řeší lépe (i když do detailu jsem ty zdrojáky nezkoumal).
Někdy by prostě neškodilo místo používání frikulínských programovacích jazyků raději oprášit základy softwarového inženýrství a základní dobré postupy. Ty nové jazyky lze samozřejmě používat taky, ale základ a podstata je trochu někde jinde a na to se bohužel často zapomíná.
-
Pavel TišnovskýZlatý podporovateljj přesně - pokud máte už datovou strukturu představující řádky tabulky a chcete ji přímo použít, tak je dobrá ta poslední knihovna. Na druhou stranu pokud je už v kódu sada fmt.Print..., tak přidat tam taby by nemusel být problém - v podstatě prakticky bez práce se dojde k lepšímu výsledku *.
Taby v source datech by asi řešil běžný string.Replace...
* myslím to tak, že ve spoustě zdrojáků (třeba i céčkových) je někdy vidět snaha o vykreslení tabulky, kde se buď specifikuje šířka sloupců (a potom se tam data nemusí vlézt) nebo se používají neelastické (běžné) taby, což je taky problém pro různou šířku dat
-
Pavel TišnovskýZlatý podporovatel
Resp. přesněji - pro data z různých zdrojů, které mohou obsahovat i Taby, nebude dobře fungovat první knihovna, ale ty další dvě budou. Akorát ta druhá nutí k převodu dat na řetězec explicitně, třetí to dělá implicitně. Vhodné jsou oba přístupy, každý někdy jindy.
-
"Někdy by prostě neškodilo místo používání frikulínských programovacích jazyků raději oprášit základy softwarového inženýrství a základní dobré postupy"
Fríkulínských jazyků je určitě spousta, ale zrovna Go tam asi nebude. naopak, ten jazyk staví na původních koncepcích C a Pascalu (+CSP), akorát neopakuje některé chyby. Asi těžko dnes hledat pragmatičtější jazyk...
-
Na tohle má Go idiomatický pattern - buď struktura podporuje předepsané rozhraní (pak se použije přímo to rozhraní a není nutná reflexe), nebo se použije relfexe na libovolnou třídu. To je asi nejflexibilnější řešení, kdo chce, dopíše si potřebné metody, jinak to prostě poskládá reflexe nějak defaultně.
-
Ten "tableprinter" je sice hezky flexibilní, ale založený na reflexi (což není nutně špatně, ale taky to pak není pro každý kontext). Podle "základů softwarového inženýrství" by ty vypisované struktury měly implementovat nějaké rozhraní, které by pak ta knihovna používala - tak se dá vyhnout reflexi při zachování flexibility (a je to idiomatické Go). Nicméně v praxi i ta základní zabudovaná funkčnost většinou stačí, může tam být navíc Join a pak hned Split, ale celkově se zbytečná režie amortizuje (ostatně samotné "fmt" taky těžce používá reflexi).
ČLÁNKY DO MAILU