Co si myslíte o OOP?

[v]

mi nějak nedochází jak to funguje, např. mám strukturu x = (y, z), tak pro (f x) se provede (f y) a (f z) a hodnota (f x) se určí jak?

https://tour.golang.org/methods/10

děkuji, ale asi jsem se zeptal blbě

[Reklama]

[Mirek Prýmek]

děkuji, ale asi jsem se zeptal blbě

Nebo jsem blbec já, to je v poho, zkus to třeba jinak

[BaldSlattery]

A v kterém rozhraní má tedy být uvedena metoda např. pro hmotnost?
Smalltalk SERE na rozhraní či třídy, Smalltalk posílá zprávy, objekt vrací hodnotu, nebo chybu. To je celé!

Tak sem dej kód pro ten batoh

Kód: [Vybrat]

batoh := Bag new.
batoh add: (Kámen ofSize: 10 andWeight: 20).
batoh add: (Sekyrka ofMaterial: #ocel andWeight: 20).
batoh add: (Hovno ofColour: #tmavěHnědá andWeight: 120).

batoh sum: [ :x | x weight ].

"se zohledněním nevhodného prvku"
batoh sum: [ :x | [ x weight ] ifError: [ 0 ] ].


No super, takže v Go se to řeší za běhu úplně stejně pomocí typové aserce, kde je teda problém? Mimochodem moderní Smalltalk má protokoly taky, protože bez nich vzniká prasokód.

[v]

děkuji, ale asi jsem se zeptal blbě

Nebo jsem blbec já, to je v poho, zkus to třeba jinak

zkusil jsem to obvyklým způsobem - nainstaloval go, vyzkoušel si to a zřejmě jsem to chápal blbě, představoval jsem si něco jako conditional conformance ze swiftu

[BaldSlattery]

představoval jsem si něco jako conditional conformance ze swiftu

Ta ale k životu potřebuje generika, ne?

[Reklama]

[Mirek Prýmek]

zkusil jsem to obvyklým způsobem - nainstaloval go, vyzkoušel si to a zřejmě jsem to chápal blbě, představoval jsem si něco jako conditional conformance ze swiftu

Rule of thumb: neočekávat od Go nic, co by mohlo budit dojem pokročilosti

P.S. conditional conformance jsem neznal, je to zajímavý, dík za zmínku

[Inkvizitor]

Chapu, ze pristup Go ma svoje vyhody a muze byt prijemny, na druhou stranu zase nevidim zadnou zvlastni komplikaci v tom, ze implementaci interface/traitu musi autor explicitne deklarovat. Typovy system to pozna, prekladac to validuje, prace s tim prakticky zadna neni

No kdyz muze prekladac najit definici traitu kdekoli ve zdrojacich, tak uplne stejne muze najit i ten konflikt, takze to mi uplne jako argument neprijde.

Možná jsme se nepochopili, já jsem to moc nerozvedl. Může nastat situace, kdy chci naimplementovat v jednom typu dva traity se stejnou metodou (signarurou metody a bez explicitního přiřazení do daných traitů to nejde udělat. Pak samozřejmě musím mít způsob, jak danou metodu vybrat, když ji potřebuju volat:

https://stackoverflow.com/questions/44953197/how-do-i-disambiguate-traits-in-rust

Konflikt překladač najít může, ale vyřešit ho neumí. Další věc je, že pokud se sejdou dva traity se stejnou signaturou metody, je dost možné, že ta metoda nemá tu samou sémantiku, byť se jmenuje stejně. Takže já mám interface, Pepa zvolil jméno metody stejné jako je v interface, takže formálně ten interface naimplementoval, přijde Karel a bezelstně začne ten interface s tím typem používat, jenže ono to dělá trochu něco jiného, než Karel a autor toho interface předpokládali. V tomhle je nevýhoda duck typingu - předpokládat, že to samé slovo znamená vždy totéž, je obecně naivní. V uzavřeném ekosystému, kde si všichni rozumějí skoro i beze slov, problém nenastává, ale v "promiskutním" prostředí, kde se do produktu míchá X programátorů a skládá výsledek z Y externích knihoven, problém může být velký.

[Mirek Prýmek]

přijde Karel a bezelstně začne ten interface s tím typem používat, jenže ono to dělá trochu něco jiného

K tomu ale může dojít i bez interfejsů. Pokud si jenom podle názvu metody myslím, že něco dělá, tak se můžu splést
Celkem ale souhlasím, asi to docela nebezpečné je.

(Takže ve finále jsem došel k tomu, že vlastně ty implicitní interfejsy vůbec nejsou dobrej nápad )

[Sunar]

přijde Karel a bezelstně začne ten interface s tím typem používat, jenže ono to dělá trochu něco jiného

K tomu ale může dojít i bez interfejsů. Pokud si jenom podle názvu metody myslím, že něco dělá, tak se můžu splést
Celkem ale souhlasím, asi to docela nebezpečné je.

(Takže ve finále jsem došel k tomu, že vlastně ty implicitní interfejsy vůbec nejsou dobrej nápad )

Čekal jsem, kdy na to přijdete. Zen of Python: Explicit is better than implicit.

[tralala]

lenze kompilator a jazyk je len tak blbovzdorny jak si ho spravis.

uz samotna premisa "dva traity rovnaka metoda" je blbost. mas to na prd navrhnute ked to niekto takto pouzije.

v scale ked ti toto nastane, tak je tam tzv linearizacia tych traitov. riesi to dobre znamy diamond problem

https://www.trivento.io/trait-linearization/

[Mirek Prýmek]

Zen of Python: Explicit is better than implicit.

Třeba explicit types?

Zen of the World: všechna všeobecná tvrzení jsou nepravdivá.

[Sunar]

Taky si to myslím. Typový systém nahradit testy jde.

Nahraď mi prosím typy za testy u tohoto příkladu:

Kód: [Vybrat]

inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.

Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?

[v]

Taky si to myslím. Typový systém nahradit testy jde.

Nahraď mi prosím typy za testy u tohoto příkladu:

Kód: [Vybrat]

inc (x: Int) = x + 1Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.

Testy se nedělají na jeden řádek kódu, ale na funkční celek, třeba funkci. Jak typem zkontroluješ, že jsi omylem nenapsal 2 místo 1?

třeba

Kód: [Vybrat]

inc :: Nat n -> Nat (S n)

[Sunar]

Zen of Python: Explicit is better than implicit.

Třeba explicit types?

Zen of the World: všechna všeobecná tvrzení jsou nepravdivá.

Většina tvých tvrzení je všeobecná.

Na typy se to dá vztáhnout také, ale spíše na implicitní versus explicitní přetypování, tedy slabé vs. silné typy.

[v]

představoval jsem si něco jako conditional conformance ze swiftu

Ta ale k životu potřebuje generika, ne?

to ano, ten můj chybný dojem byl, že když všechny prvky struktury (nebo pole) jsou typu který implementuje rozhraní, tak struktura implementuje rozhraní