Postřehy ohledně architektury JavaScriptu

SB

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #135 kdy: 26. 08. 2016, 13:51:59 »
Takže bez zapouzdření, protože i když budete mít v package jen jednu třídu, i její instance budou vzájemně nezapouzdřené (stejně jako v C# a Javě).


zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #136 kdy: 26. 08. 2016, 13:52:56 »
Sranda ako tu onanujete nad tým dementným jazykom a reálne patláte trápne webiky. JavaScriptári sú najväčšia háveď pod slnkom. Vymýšľať nejaké šialené super teoretické psychopatiny je príznak toho, že ste na programátori na nič.

ja si nemyslim ze ten jazyk je dementni - on me prijde jenom ze ma strasne moc moznosti a tim padem se domluvit nad necim nad nim je  slozity a dochazi tam k mnoha nepochopenim ... ale zpet k te otazce at uzavrem aspon to klonovani kdyz uz nic at ma tohle vlakno alespon nejaky zaver kdyz uz sem to zacal (i kdyz toho ted trosku lituju) ... :}

takze proc je potreba tak strasne klonovat objekty? :) nemeli by ty prototypy slouzit predevsim k tomu ze definuji strukturu a hierarchii ze ktere pak tvorim instance a pomoci 'konstruktoru' potom definuju jejich vychozi stav ktery dale upravuje jen proces (jednotlive kroky programu? :) ) nebo to je v js spatny pristup?

diky
Pochopitelně k vytváření objektů slouží konstruktory. Celá tato debata je ukázkou "cargo cult programming", kdy se sofistikované koncepty naprosto nelogicky aplikují úplně mimo bez jejich pochopení. Je to něco jako posadit opici před psací stroj, román z toho taky nikdy nevznikne.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #137 kdy: 26. 08. 2016, 13:56:02 »
Ad 2: Go nějak přidělává práci?

Ano. Nemá zapouzdření.

Encapsulation: the ability to restrict or provide access to data and the ability to tie behavior or methods with the data. For Go some of the salient features are:
* There are two levels of access - within the package alone, and public.
* If a field, type, or method starts with a capital letter it is exported outside the package and is public. If instead it starts with a small letter, it is visible only within the package.
* Exported/public items: MyStruct, MyMethod, MyField
* Items with package visibility: myStruct, myMethod, myField
* You can tie in methods/behavior to a type by defining functions associated with it. func (m my_type) my_func() int { }
* You cannot attach methods to a type if it is not defined in the local package.
Díky, ušetřil jsem příspěvek. V praxi je tato kontrola přístupu naprosto dostačující.

SB

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #138 kdy: 26. 08. 2016, 14:41:52 »
Pochopitelně k vytváření objektů slouží konstruktory...

Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.

...Celá tato debata je ukázkou "cargo cult programming", kdy se sofistikované koncepty naprosto nelogicky aplikují úplně mimo bez jejich pochopení...

Jo, právě to si myslím o vás.

SB

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #139 kdy: 26. 08. 2016, 14:44:58 »

Encapsulation: the ability to restrict or provide access to data and the ability to tie behavior or methods with the data. For Go some of the salient features are:
* There are two levels of access - within the package alone, and public.
* If a field, type, or method starts with a capital letter it is exported outside the package and is public. If instead it starts with a small letter, it is visible only within the package.
* Exported/public items: MyStruct, MyMethod, MyField
* Items with package visibility: myStruct, myMethod, myField
* You can tie in methods/behavior to a type by defining functions associated with it. func (m my_type) my_func() int { }
* You cannot attach methods to a type if it is not defined in the local package.
Díky, ušetřil jsem příspěvek. V praxi je tato kontrola přístupu naprosto dostačující.

Mluvte za sebe, ne za ostatní.


zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #140 kdy: 26. 08. 2016, 15:07:47 »
Pochopitelně k vytváření objektů slouží konstruktory...

Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.

...Celá tato debata je ukázkou "cargo cult programming", kdy se sofistikované koncepty naprosto nelogicky aplikují úplně mimo bez jejich pochopení...

Jo, právě to si myslím o vás.
V tomto konkrétním případě mám ostatně jen stejný názor jak Rob Pike. Jestli se můžeš odvolat na nějakou podobnou kapacitu, rád si poslechnu odborný (akademicky podložený) názor. Jinak tuto diskusi odložme, až budeš mít aspoň PhD, ne že bych se na takové úrovni odmítal bavit, ale potřebuju k tomu hospodu a pivo ;)

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #141 kdy: 26. 08. 2016, 15:11:44 »
Sranda ako tu onanujete nad tým dementným jazykom a reálne patláte trápne webiky. JavaScriptári sú najväčšia háveď pod slnkom. Vymýšľať nejaké šialené super teoretické psychopatiny je príznak toho, že ste na programátori na nič.
Chcípni pičo

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #142 kdy: 26. 08. 2016, 15:17:04 »
Sranda ako tu onanujete nad tým dementným jazykom a reálne patláte trápne webiky. JavaScriptári sú najväčšia háveď pod slnkom. Vymýšľať nejaké šialené super teoretické psychopatiny je príznak toho, že ste na programátori na nič.

ja si nemyslim ze ten jazyk je dementni - on me prijde jenom ze ma strasne moc moznosti a tim padem se domluvit nad necim nad nim je  slozity a dochazi tam k mnoha nepochopenim ... ale zpet k te otazce at uzavrem aspon to klonovani kdyz uz nic at ma tohle vlakno alespon nejaky zaver kdyz uz sem to zacal (i kdyz toho ted trosku lituju) ... :}

takze proc je potreba tak strasne klonovat objekty? :) nemeli by ty prototypy slouzit predevsim k tomu ze definuji strukturu a hierarchii ze ktere pak tvorim instance a pomoci 'konstruktoru' potom definuju jejich vychozi stav ktery dale upravuje jen proces (jednotlive kroky programu? :) ) nebo to je v js spatny pristup?

diky
Pochopitelně k vytváření objektů slouží konstruktory. Celá tato debata je ukázkou "cargo cult programming", kdy se sofistikované koncepty naprosto nelogicky aplikují úplně mimo bez jejich pochopení. Je to něco jako posadit opici před psací stroj, román z toho taky nikdy nevznikne.
Konstruktory jsou jen jedna cesta, BTW ty konstruktory v JS mě spíš připomínaj factory...

Druhá cesta je klonování objektů, v JS se tenhle způsob tvorby objektů nepoužívá, pokud vím, v některých prototype based OOP implementacích byl tenhle princip použit. Detaily neřeknu, znám nejlíp JS.

Tím chci říct, nemluv jako kdyby tady nebyla jiná cesta, brání to inovacím

YF

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #143 kdy: 26. 08. 2016, 16:00:33 »
Tenhle problem mame s detmi: kdyz sme jim koupili moc hracek - nehrali si ani s jednou, vsechny rozhazeny a rozbity - ale meli jich hodne a mohli donekonecna premyslet o tom s cim si budou hrat aniz by si s nima vlastne hrali. Tak sem se jednou nastval - a protoze neuklizely tak sem ty vsechny hracky nahazel do pytle - nechal jim prazdnej pokoj jen s jednou stavebnici - a ted postupne pridavam hracky podle toho jak si poradili s tema co uz maji ... :) Nic - dekuji za prispevky - ja myslim ze obrazek sem si udelal - tak se mejte.


SB

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #144 kdy: 26. 08. 2016, 16:05:21 »
V tomto konkrétním případě mám ostatně jen stejný názor jak Rob Pike. Jestli se můžeš odvolat na nějakou podobnou kapacitu, rád si poslechnu odborný (akademicky podložený) názor. Jinak tuto diskusi odložme, až budeš mít aspoň PhD, ne že bych se na takové úrovni odmítal bavit, ale potřebuju k tomu hospodu a pivo ;)

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." Alan Kay http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

Nepředpokládám, že Kay měl na mysli nějaké částečné zapouzdření (hiding), které někdy funguje a někdy ne.

Zato já už nemám náladu dohadovat se s nějakými céčkaři přeškolenými na OOP, chci se vrátit k původnímu tématu, a to je Javascript a jeho použití. Jestli máte potřebu protřepávat způsob, jak pozalamovat OOP do Go, založte si pro to jinou diskusi.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #145 kdy: 26. 08. 2016, 16:16:13 »
V tomto konkrétním případě mám ostatně jen stejný názor jak Rob Pike. Jestli se můžeš odvolat na nějakou podobnou kapacitu, rád si poslechnu odborný (akademicky podložený) názor. Jinak tuto diskusi odložme, až budeš mít aspoň PhD, ne že bych se na takové úrovni odmítal bavit, ale potřebuju k tomu hospodu a pivo ;)

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them." Alan Kay http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

Nepředpokládám, že Kay měl na mysli nějaké částečné zapouzdření (hiding), které někdy funguje a někdy ne.

Zato já už nemám náladu dohadovat se s nějakými céčkaři přeškolenými na OOP, chci se vrátit k původnímu tématu, a to je Javascript a jeho použití. Jestli máte potřebu protřepávat způsob, jak pozalamovat OOP do Go, založte si pro to jinou diskusi.
To chápu, céčkaři jsou divná stvoření, taky jsem jim nepříšel na chuť. Stejně jako javascriptařům. Programování ostatně není věda, ale čistě praktická a pragmatická činnost, něco jako tesařina, a absolutně nemá smysl se bavit o tom, jaká míra zapouzdření je žádoucí, protože to závisí na kontextu. Takže cargo kult pozdravuje :p Prvním krokem k přechodu od žvanila k odborníkovi - přiznávám, ne každý na to intelektuálně má - bude naučení se věcné diskusi...

Thorn

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #146 kdy: 26. 08. 2016, 17:28:44 »
Citace
Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.

Ale jistě. V JavaScriptu se dá snad všechno udělat na sto způsobů. Jen některé z těch způsobů jsou jaksi zavedené a očekávané, jiné pak méně vhodné. Dělat něco jinak než zbytek jenom proto, že TO TAKY JDE(čumte, co jsem se včera naučil!) není ta správná cesta, pokud nehodláš do smrti dělat one-man show.

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #147 kdy: 26. 08. 2016, 18:17:50 »
Konstruktory jsou jen jedna cesta, BTW ty konstruktory v JS mě spíš připomínaj factory...

Druhá cesta je klonování objektů, v JS se tenhle způsob tvorby objektů nepoužívá, pokud vím, v některých prototype based OOP implementacích byl tenhle princip použit. Detaily neřeknu, znám nejlíp JS.

Tím chci říct, nemluv jako kdyby tady nebyla jiná cesta, brání to inovacím

Konkrétně třeba v Selfu a v Rebolu. V Selfu je to celé vymyšlené poměrně dobře a taky to byla jedna z inspirací pro javascript, bohužel se to ale povedlo kompletně posrat, od chybějící delegace po právě kopírování / klonování a bez toho je prototype-based OOP model jen parodie sebe sama.

Viz třeba:


gl

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #148 kdy: 26. 08. 2016, 18:54:34 »
Zboji jsi stejnej debil jako javaman. Až budou prohlížeče umět haskell a všichni programátoři budou mít Phd z teorie programovacích jazyků, tak budou tvoje výblitky možná někoho zajímat.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #149 kdy: 26. 08. 2016, 19:47:31 »
Citace
Objekt lze vytvořit více způsoby, konstruktor je jenom jedním z nich.

Ale jistě. V JavaScriptu se dá snad všechno udělat na sto způsobů. Jen některé z těch způsobů jsou jaksi zavedené a očekávané, jiné pak méně vhodné. Dělat něco jinak než zbytek jenom proto, že TO TAKY JDE(čumte, co jsem se včera naučil!) není ta správná cesta, pokud nehodláš do smrti dělat one-man show.
To je znak začínajících programátorů, použít právě naučené fancy věcičky, když by to šlo elegantně a jednoduše. Neštěstí je, když pak někdo normální musí ten prasokód (bez getterů, setterů, else, zato s milionem returnů a deep klonováním každého s prominutím h***a) číst. I v tom JS jde psát rozumně, jen to ten JS jaksi nevyžaduje :(