Příspěvky

436

Vývoj / Re:Trait a konstruktor

« kdy: 23. 12. 2020, 17:21:16 »

V tomhle kontextu mi přijde, že i tvé rozlišení v tom, že class znamená "být" a trait znamená "mít" se smývá, protože pokud něco jsem, tak to i mám, "mít" je silnější.

No samozřejmě. Problém je v tom, že se na to díváš z druhé strany. Já chci do objektu přidat chování a atributy, ale nechci, aby se mi tím změnil typ například. Tedy chci aby zůstalo "mít", ale nezměnilo se "být".

Usecase, které pro traity mám (a které se samozřejmě může lišit jazyk od jazyka):

Mám nějaký objekt. Chci, aby tento objekt měl určité vlastnosti. Buď tam ty vlastnosti dopíšu, nebo je "přidám" pomocí traitu (protože stejné chování jsem dělal jinde). Přičemž vlastnostmi je jak chování (vlastní nějaké metody), tak i data (vlastní nějaké atributy), tak i kategorie (objekt implementuje nějaké rozhraní). A samozřejmě nechci být omezován, takže mohu přidávat kteroukoliv z těchto tří vlastností - ne jak je to u dědičnosti.

437

Vývoj / Re:Trait a konstruktor

« kdy: 23. 12. 2020, 17:12:13 »

Navíc trait má popisovat nějaké chování, funkce, neměl by obsahovat data.

Hele, takhle uvažovat nemůžeš. V jazycích jako je Java, C#, PHP jsou class to, co je v Haskellu type. To co je v Haskellu class je v Java interface... Takže prohlašovat, že v traitu něco být nemá, je takové nepraktické. V zadání bylo co tam bylo. Neupravujme ho.

438

Vývoj / Re:Trait a konstruktor

« kdy: 22. 12. 2020, 20:16:21 »

Dotty (Scala 3) podporuje parametrizované traity. (A také "intersection types", které mohou při práci s traity přijít vhod.)

Hmm, jaký pak zbývá rozdíl mezi trait a class kromě toho, že není možné dědit z více class najednou? Co by se stalo, kdyby se klíčové slovo class zrušilo a používaly se jen tyhle nové traity?

Nevím jak Dotty, ale základní rozdíl mezi dědičností a traity je v té dědičnosti. Když máš objekt O, do kterého přidáš trait T, tak ten objekt O není tím T. (Maximálně tak T obsahuje.) Zatímco když O dědí od předka P, tak O je P.

Jako asi pro tebe nic nového, ale tohle je prostě ten rozdíl ¹. To je všechno.


1/ Tak maximálně ještě, že metody z traitu se obvykle nepřetěžují, že se s tím trochu jinak pracuje, a tak.

439

Vývoj / Re:Trait a konstruktor

« kdy: 21. 12. 2020, 21:31:24 »

Mirnou oklikou zpet.... Nebylo by treba hezci aby ten koho obohacuju traitem o tom vubec nemusel vedet?

Beru zpet, protoze vlastne nevim jak to udelat.... To co sem myslel nefunguje tak jak sem myslel...

Nesplňuje to dědičnost nebo dekorátor?

440

Vývoj / Re:Trait a konstruktor

« kdy: 21. 12. 2020, 19:37:54 »

Nemam pocit, ze bych nekde psal, ze trait souvisi s DI.

V poho. Reagoval jsem na celé vlákno. Netušil jsem, že tuhle blbost někomu bude stát za to rozvíjet.

im, ze je tam rozdil, ale nevidim ze by u toho traitu ta zavislost byla mene priznana.

Podle mě ses zaměřil na obecný význam slova "závislost", ale ne na skutečnou funkci DI třeba v tom konstruktoru. Trait řeší chování celé třídy (typu), DI rozhoduje o situaci či chování konkrétní instance.

Přesně. Navíc DI je zpravidla runtime kdežto traity compile time. Někdy potřebujeme to a jindy ono.

Me slo o pojem "priznani zavislosti". S durazem na priznani. Prijde mi to, ze to neprimo znamena u traitu zavislost neni, nebo ze neni videt. Coz je podle me zavadejici. DI je o tom, ze si nemusim vyrabet nastroj kterym neco udelam, ale nekdo mi ho doda. Ale musim vedet jak to pouzit. O traitu toho ja moc vedet nemusim, protoze ja ho nemusim pouzivat, ale v compile time na nej stejne deklaruju zavislost.

Trait souvisí s DI asi stejně jako souvisí s DI funkce str_concat() v následujícím kódu:

Kód: [Vybrat]

class Foo {
    string format(s :  string) : string {
       return str_concat("[", s, "]")
    }
}

Je to závislost? Je. Je přiznaná či nepřiznaná? Eee... Mluvil by někdo normální o tom jako o DI?

Nemam pocit, ze bych nekde psal, ze trait souvisi s DI.
Jen se ohrazuju proti tvrzeni ze DI je o priznani zavislosti.

Pripad bez DI a bez traitu:
Potrebuju zatlouct hrebik... vyrobim si kladivo.

DI:
Potrebuju zatlouct hrebik... podej mi kladivo

Trait:
Potrebuju zatlouct hrebik... ja jsem mimo jine taky kladivo.

Vsude mam zavislost na kladivu. V prvnim a tretim pripade mam zavislost dokonce na konkretni implementaci. S DI se nekdo muze rozhodnout v runtimu jaky kladivo dostanu a zavisim jen na interfacu.

Z kontextu predpokladam, ze se bavime o "dependency injection" a ne o "dependency inversion".

Řekl bych, že takto to není. Trvám na tom, že DI (dependency injection) je o přiznání závislostí.

DI: abych mohl fungovat, dej mi kladivo
neDI: budu fungovat, kladivo si seženu

to je celé, víc v tom není.

Trait je úplně něco jiného. DI může respektovat, stejně jako nemusí.

441

Vývoj / Re:Trait a konstruktor

« kdy: 21. 12. 2020, 19:01:08 »

...

Díky za příspěvek.

442

Vývoj / Re:Trait a konstruktor

« kdy: 21. 12. 2020, 18:14:02 »

Dotty (Scala 3) podporuje parametrizované traity. (A také "intersection types", které mohou při práci s traity přijít vhod.)

Kód: [Vybrat]

trait Polite(text: String) {
  val greeting = init(text)
  def greet(name: String) = s"$greeting $name!" 
  private def init(s: String) = s"${text.toUpperCase},"
}

trait Curious(val question: String)

class MessageStyle(g: String) extends Polite(g) with Curious("How are you?")

def composeMessage(data: Polite & Curious, name: String): String = {
  s"${data.greet(name)}\n${data.question}"
}

object Main extends App {
  val messageStyle = MessageStyle("hello")
  println(composeMessage(messageStyle, "World"))
}

(https://scastie.scala-lang.org/VCcgilMpRMWpnZ773wMJIw)

Hezký.

Žel, opět se musím zeptat: Jde nějak ještě když bych tomu chtěl přidat nějakou logiku? Tedy konstruktor MessageStyle přijme g, přepočítá ho, a teprve výsledek uloží do fieldu Polite(g).

443

Vývoj / Re:Trait a konstruktor

« kdy: 21. 12. 2020, 17:55:09 »

im, ze je tam rozdil, ale nevidim ze by u toho traitu ta zavislost byla mene priznana.

Podle mě ses zaměřil na obecný význam slova "závislost", ale ne na skutečnou funkci DI třeba v tom konstruktoru. Trait řeší chování celé třídy (typu), DI rozhoduje o situaci či chování konkrétní instance.

Přesně. Navíc DI je zpravidla runtime kdežto traity compile time. Někdy potřebujeme to a jindy ono.

Me slo o pojem "priznani zavislosti". S durazem na priznani. Prijde mi to, ze to neprimo znamena u traitu zavislost neni, nebo ze neni videt. Coz je podle me zavadejici. DI je o tom, ze si nemusim vyrabet nastroj kterym neco udelam, ale nekdo mi ho doda. Ale musim vedet jak to pouzit. O traitu toho ja moc vedet nemusim, protoze ja ho nemusim pouzivat, ale v compile time na nej stejne deklaruju zavislost.

Trait souvisí s DI asi stejně jako souvisí s DI funkce str_concat() v následujícím kódu:

Kód: [Vybrat]

class Foo {
    string format(s :  string) : string {
       return str_concat("[", s, "]")
    }
}

Je to závislost? Je. Je přiznaná či nepřiznaná? Eee... Mluvil by někdo normální o tom jako o DI?

444

Vývoj / Re:Trait a konstruktor

« kdy: 20. 12. 2020, 23:09:07 »

Souhlas, že traity a DI jsou částečně zastupitelné přístupy. Vhodnost jednoho či druhého záleží IMHO na okolnostech.

Nemohu souhlasit. Tyto dva koncepty spolu nijak nesouvisí. Traity jsou o lepení kódu. DI je o přiznání závislostí. Nebe a dudy.

445

Software / Re:Proč se ve školách a firmách používají MS Produkty?

« kdy: 20. 12. 2020, 23:03:26 »

Třeba moje děti (4 třída ZŠ) nemají problém s příkazovou řádkou. Příkazová řádka mi přijde jako jeden z nesrozumitelnějších a nejsprávnějších přístupů, jak ukázat funkce počítače. Dialog otázka - odpověď v terminál session je názorná a analogická reálnému světu, nepoutá pozornost barvičkama a nesmyslama, které v podstatě pouze vtahují do klamavého virtuálního světa. Počítač je stroj a dítě ho má primárně jako stroj chápat. Děti nemají problém poslat mail, vyhledat něco na internetu, tam používají GUI, ale didakticky dává smysl jít od příkazové řádky.

Tak příkazová řádka je určitá forma chatu.

Vidím v tom dva takové rozměry:

První rozměr je v tom, že ta příkazová řádka jak ji známe je poněkud hodně low level. Něco napíšeš, a ten stroj ti vybleje změť znaků či textu, ve kterém se pokoušíš zorientovat. Nějaký tabulky, seznamy, obrázky - dalo by se toho hodně vylepšovat.

Druhý rozměr je v tom, že některým mladým (nechci generalizovat, takže neříkám zda více či méně) činí problém vyjádřit myšlenku. A vést konstruktivní dialog je nad jejich síly. Ale možná by je to naopak přinutilo, aby se to naučili.

Aktuální stav vidím v tom, že příkazová řádka je nedostatečná, a tak mají mladí oprávněnou výmluvu se na ni dívat svrchu.

446

Vývoj / Re:Trait a konstruktor

« kdy: 20. 12. 2020, 02:33:33 »

...

Díky za příspěvek.

447

Vývoj / Re:Trait a konstruktor

« kdy: 19. 12. 2020, 17:00:53 »

... nelíbilo by se mi, že v definici UserAccount není jasně na jednom místě vidět, jaké fieldy nakonec v té třídě budou, člověk si musí projít všechny traity zvlášť, a přitom fieldy a jejich typy bývají pro porozumění kódu většinou to nejdůležitější.

On ten dotaz tak trochu vycházel z mého požadavku toho DSLka. Kde se to používá trochu naopak. Většinou si prohlížíš ten výsledný typ, se všema fieldama a behaviours, co to cestou posbíralo. A teprve sekundárně doklikáváš, kde je to nadefinované.

Ale pokud tě napadá jaká další úskalí to může mít, sem s tím.

448

Software / Re:Proč se ve školách a firmách používají MS Produkty?

« kdy: 19. 12. 2020, 04:41:40 »

A protože mám Linux rád, budu ho podporovat, a budu se snažit, aby Linux nebyl oneman show.

Stejně jako v začátcích byl Linux jen příkazová řádka, a nyní má desktop lepší jak Windows, tak se třeba dočkáme i nějakého dostatečně blbuvzdorného řešení, které umožní spravovat instalace centrálně a la AD. Pár adeptů se už rýsuje.

Pokud pomineme vase "doufani v lepsi zitrky" v soucasne dobe jste pro windows?

Ekonomicky, a na školách či úřadech, kde je třeba centrální správa - ano. Ale beze mě. (Čímž neříkám, že když bych se nedejbože objevil na nějakém takovém místě a měl to na starost, tak že bych nezkoušel uvažovat o alternativě. Ale zatím Linux stále není lepší, a bejt stejně dobrý nestačí.)

V domácnostech určitě ne. Ale tak otázka nezněla, vím.

449

Vývoj / Re:Trait a konstruktor

« kdy: 19. 12. 2020, 01:44:11 »

V první otázce zní: Nezneužívat dědičnost, radši na to vzít traity. Já říkám: Ale já vidím kompozici, k té traity nepotřebuju. Odpověď: V kontextu OOP je to jinak. Tak jak je to? Co je trait?

To máš buřt.

Abych nebyl za kverulanta, já bych prostě inicializoval v konstruktoru, kde bych volal konstruktor traitu. Nebo je myšlena nějaká automatická inicializace? Asi nerozumím té otázce. Je to otázka po syntaxi, sémantice, runtime? Všechno je možný - můžu inicializovat aspektem, anotací...

Takhle?:

Kód: [Vybrat]

class Foo {
    use A;
    use B;
    public constructor(int id, string name) {
        A.constructor(id);
        B.constructor(name);
    }
}

Asi nerozumím té otázce. Je to otázka po syntaxi, sémantice, runtime? Všechno je možný - můžu inicializovat aspektem, anotací...

Syntaxe.

Jak tyto vlastnosti inicializovat, případně když ta inicializace má nějakou komplexní logiku. Proč by to měl být problém souvisí poněkud s tím, že ty fieldy z traitu jsou privátní, mají nějaký provázaný stav, který by si měl hlídat ten trait.

450

Software / Re:Proč se ve školách a firmách používají MS Produkty?

« kdy: 18. 12. 2020, 23:48:24 »

No, já se obávám, že naopak toto trolliování je zhoubou. Snad vám podobné přežijeme pro změnu my.

No, napsat, že mě vyhovuje Linux na desktopu - beru.
Napsat to o ostatních, tváří v tvář procentu uživatelů (a i to jsem možná přehnal), je trollování.
Napsat cokoliv a na jakoukoliv reakci označit ostatní za trolly, to je taky trollování.

Nechte to, až budete střízlivý, nebo jinak v kondici.

Hodně by pomohlo, kdy by jste si přestal vymejšlet. Každopádně troll detected, sbohem.