Portál AbcLinuxu, 30. dubna 2025 06:32
V předchozím dílu článku jsme načali prohlídku sémantických prvků, ze kterých může programátor v Go skládat svá díla. V dnešní části se opět letmo podíváme na některé další, dosud netknuté „kostky“ stavebnice a tím úvodní Go miniseriál uzavřeme. Případné budoucí další články na téma Go by se již měly nejspíše věnovat konkrétním tématům a jejich řešení v Go.
Místní proměnné mohou být deklarovány uvnitř bloku a mohou překrývat stejně nazvané proměnné vyšší úrovně (analogicky jako v jazyce C). Trochu podobně jako u stylu psaní složených závorek existují dva tábory těžko smiřitelných pohledů na jazyky, které tuto sémantiku deklarací nabízejí. Pravdou například je, že v první řadě nikdo není nucen překrývání ve svém kódu používat. Stejně pravdivé ovšem je, že tato vlastnost jazyka je zdrojem potenciálních chyb, například tehdy, když máme mylně pocit, že někde v kódu měníme vůči bloku vnější entitu, ale přehlédneme, že ta je překrytá vnitřní deklarací. Třetí podstatná skutečnost je výrazné usnadnění při refaktorizaci („přeorávání“) rozsáhlejšího kódu. Funkční bloky, uzavřené ve složených závorkách, si při svém přenášení mezi různými místy programu „vezmou“ sebou i své vůči bloku lokální proměnné a jsou pak imunní k opačné chybě, kdy nám do kontextu bloku „vpadne“ viditelnost vnější deklarace, kterou jsme neměli původně v úmyslu používat uvnitř bloku, protože na původním umístění žádná taková vnější deklarace (pravděpodobně navíc s odlišnou sémantikou užití) neexistovala.
V Go je situace ještě trochu zkomplikována možností „zkrácené“ deklarace proměnných:
var i int // Standardní deklarace proměnné 'i' s typem 'int'. i = 1234 // Přiřazení hodnoty var s string = "Hello" // Dtto s inicializátorem. // Řádek výše má stejný význam jako: var s string s = "Hello" var f = 3.14 // Deklarace a inicializace s inferencí typu. // Řádek výše má stejný význam jako: var f float64 f = 3.14 e := 2.71828 // Zkrácená deklarace (pouze s inicializátorem a inferencí typu) // Řádek výše má stejný význam jako: var e float64 e = 2.71828 // Umožňuje ale redeklarovat proměnnou 'e'.
Poslední případ se výrazně liší od svých předchůdců. V Go, podobně jako skoro v každém dalším programovacím jazyku, je jiná než první deklarace stejně pojmenované proměnné (funkce, typu) v rámci daného/jednoho kontextu (třeba bloku) pro kompilátor chybou. Zkrácená deklarace je výjimkou neboť dovoluje redeklaraci. Platnost nově deklarované proměnné je daná lexikálně:
v := 1 // začátek kontext 'v' s hodnotou 1 fmt.Println(v) v := 2 // začátek kontextu 'v' s hodnotou 2.
Pravidla pro zkrácené deklarace a redeklarace jsou dokonce ještě o trochu složitější a začátečníci v Go se v nich často dopouštějí chyb, ovšem jen protože se s nimi neseznámili dostatečně. Nejde o to, že by v celku ona pravidla byla složitá nebo nelogická, jen jsou neobvyklá ve smyslu, že jsou (asi) unikátní pro Go.
Téma je to opět na samostatný článek, zde alespoň odkaz na předmětnou specifikaci.
Uzávěry jsou známy také jako closures. To první (globální proměnné) je v Go stejné jako v C (ale ne v Javě). To druhé, tedy uzávěry, C v pravém slova smyslu neumí (mimo nestandardních rozšíření). Java to teprve připravuje a zase naopak Javascript je zná od začátku.
Triviální případ uzávěry v Go jsme si ukázali v minulé části v odstavci Paralelismus, v daném případě je proměnná 'c' součástí uzávěry anonymní funkce třídění. Jinou „školní“ ukázkou je třeba schéma uzávěry numerické derivace reálné funkce jednoho parametru:
package main
import "fmt"
type fx func(float64) float64
func derivative(f fx, dx float64) fx {
return func(x float64) float64 {
return (f(x+dx) - f(x)) / dx
}
}
func main() {
df := derivative(
func(x float64) float64 {
return x * x
},
1e-8,
)
fmt.Println(df(1), df(2), df(3))
// výstup: 1.999999987845058 3.999999975690116 5.999999963535174
}
Nerad v tomto případě opět odbývám laskavého čtenáře níže odkazovanými texty, ale zde jsme bohužel už zase u problematiky na minimálně celý článek...
V Go je možné vyvolat explicitní výjimku (panic), s předáním instance libovolného typu jako parametru výjimky. Implicitně výjimka ukončí program s výpisem trasy zásobníku na stderr a pokud je parametr převeditelný na řetězec, vypíše se také.
Navíc je možné výjimky zachytit (defer) s možností ošetření (recover) a pokračování běhu v místě ošetření, pokud to přichází v úvahu (ne, když si generál Failure pročítá váš hardisk).
Mechanismus panic/defer má obdobnou sémantiku jako try/except/catch/finally v jiných jazycích, ale jinou formu zápisu a z ní plynoucí i jiný způsob jeho používání a uvažování při kódování.
Idiomatické je v Go nenechávat výjimky opustit hranice modulu a na nich předávat chybové kódy nebo objekty, v tom druhém případě jsou to typicky hodnoty implementující rozhraní os.Error.
Čtěte specifikaci a blogový zápisek k tématu.
Go podporuje objektové programování, potíž je pouze v definici toho, co to objektové programování podle koho je. Lépe bude asi uvést, co v tomto směru Go umí. K objektům (pojmenovaným typům, kterým ale může být třeba i type myInt int) je možné deklarovat metody instance, tj. funkce s tzv. přijímačem (analogické k např. 'this' nebo 'self' u jiných jazyků). Více také ve specifikaci.
Objekty v Go nemají hierarchii, ale lze je skládat (no inheritance but composition). Některé příklady jsme si ukázali v minulé části.
Zavolat metodu s ukazatelovým přijímačem nad hodnotou nil není v Go problém. K výjimce by došlo až poté, co by se taková metoda pokusila dereferencovat svůj přijímač. To umožňuje například centralizovat zachytávání chybně předaných nil instancí (pro daný typ a metodu) v jednom bodě a není pak už třeba takový test provádět v každém místě volání.
To, co se v jiných jazycích řeší často dědičností – hierachií typů, se v Go modeluje spíše pomocí rozhraní. Podstatně podrobněji se tomuto tématu věnují autoři Go třeba v tomto článku.
Zde se Go opět výrazně odlišuje od mainstream jazyků. Rozhraní v Go definuje množinu metod jimiž je rozhraní tvořeno a případně, z kterých dalších rozhraní dědí jejich množiny metod. Potud vše jako obvykle. Neobvyklé je to, že v Go to tím jakoby také končí. Typy nijak nedeklarují, že implementují nějaké rozhraní, ani rozhraní neříká nic o tom, které typy jej implementují. Pokud však jakýkoli typ implementuje všechny metody libovolného rozhraní, pak je tento typ s oním rozhraním slučitelný.
Tento koncept má některé neobvyklé důsledky. Například to, že typ může bez úprav splňovat rozhraní, které nebylo ještě v době návrhu typu definováno. Dalším ne zcela intuitivním důsledkem, zato ale velmi užívaným, protože užitečným, je to, že prázdné rozhraní, tj. rozhraní bez jakékoli metody (jeho typ jeinterface{}) splňuje v Go každý typ. Slovo každý zde platí doslova, vztahuje se tedy i na primitivní/vestavěné typy jako třeba int a string, bool, ... Zdá-li se to někomu jako výjimka nebo překvapivé, pak je třeba poznamenat, že je to naopak/jen pravidelnost v aplikaci pravidla o slučitelnost s rozhraním.
package main
import "fmt"
type talker interface {
talk()
}
type cat struct {
//...
}
func (c cat) talk() { // implementace rozhraní 'talker'
fmt.Println("mňau")
}
type dog int
func (d dog) talk() { // implementace rozhraní 'talker'
fmt.Println("haf")
}
func hello(animal talker) {
fmt.Printf("%T: ", animal)
animal.talk()
}
func main() {
hello(cat{}) // strukturovaný literál typu 'cat'
hello(dog(42)) // explicitní konverze celočíselné konstanty na typ 'dog'
// out:
// main.cat: mňau
// main.dog: haf
}
Čtěte specifikaci a blogový zápisek.
Ladění binárek vytvořených gccgo by mělo (neověřeno) být víceméně standardní záležitostí, tj. GNU GDB a jeho případné nadstavby. U 6g a spol. je situace trochu složitější, protože používaný toolchain pochází z Plan9 a podpora ladících informací, kterým by GDB rozuměl, byla zpočátku téměř nulová. Brzy už bylo možné alespoň ladit podle čísel zdrojových řádku (samozřejmě je i listovat). Nedávno byla podpora DWARF3 dat značně posílena, takže nyní je možná už i inspekce globálních i místních proměnných a trasy zásobníku, byť stále ještě s nějakými omezeními. Podrobněji v blogu na golang.org.
Začínají se objevovat zárodky budoucích Go IDE. Dle samotných vývojářů Eclipse pluginu GoClipse je jejich projekt ještě v alfa stadiu, nicméně screenshot na úvodní stránce projektu vypadá už docela zajímavě.
Stabilní jsou Go doplňky editoru vim, které jsou součástí distribuce. Podobně existuje podpora pro další editory, třeba Emacs, ale o nich autor upřímně nedokáže nic říct pro zcela nulové zkušenosti s nimi.
Pro příznivce vim/gvim existuje (vizte obrázek) udržovaný, pravidelně aktualizovaný projekt GoCode, což je z hlediska editoru neutrální nástroj pro autocompletion. Pro Vim je podpora této funkčnosti součástí distribuce GoCode, funguje tak jak má a určitě zvyšuje pohodlí a produktivitu Go programátora.
V miniseriálu Go jsme probírali opravdu jen některé vybrané/zajímavější vlastnosti Go. Pokud tato „ochutnávka“ někoho zaujala tak už asi Go zkoumá přímo u odkazovaných zdrojů. Ale ani pro ostatní (zatím nezaujaté) to možná nebyl ztracený čas. Inzerát s textem „hledáme programátory se znalostí Go“ hned tak někde nenajdete. Jestli bude Go úspěšné a takový inzerát pak skutečně jednou potkáte, třeba budete – v onen budoucí čas – rádi, že jste se o Go – možná dnes - začali zajímat. A jestli k tomu snad nějak přispěl i tento článek, pak je potěšení na straně autorů samozřejmostí.
Jan Mercl a Ondřej Surý pracují v Laboratořích CZ.NIC, výzkumném a vývojovém centru správce české národní domény.
5.4.2011 10:39
alblaho | skóre: 17
| blog: alblog
defer se mi docela líbí), odvážili se zrušit dědičnost (tleskám!) a zavést určitou formu strukturální typové ekvivalence (u rozhraní)… no, na gorutiny s posíláním zpráv se budu muset ještě trochu podívat, ale žádné velké nadšení nepozoruju.
Lambdy jsou syntakticky hrozně roztahané, skoro jako v Javě 
A proč autoři mluví o uzávěrech jako o uzávěrách?
), lambdy či uzávěry (v C++ to umí třeba Boost.Coroutine (zatím není součástí Boostu) a Boost.Lambda).
Go se mi líbí, ale mírným favoritem na podobném poli je u mě Vala.
5.4.2011 17:54
alblaho | skóre: 17
| blog: alblog
Plusem je, že nějaký kvalitní soft už je v tom napsaný, třeba Shotwell. Ale detailně jsem to nezkoumal, teď koukám, že mají i výjimky, takže to není jen blbý preprocesor pro C.
Ale mimo GNOME nevím nevím.
5.4.2011 17:58
alblaho | skóre: 17
| blog: alblog
7.4.2011 15:02
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.