Postřehy ohledně architektury JavaScriptu

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #105 kdy: 25. 08. 2016, 15:04:15 »

Deep copy je komplexny problem. To nemoze vediet uz z podtaty veci jazyk sam dobre robit.
Nežvaň mistře ...... A co strukturovaný klonovací mechanismus použitý na objekty které se posílají do workerů. Zvládne dokonce cyklicity (krom deep copy) ale už nepřenese prototypy.

No je to pekne, len zle urobena "deep copy" moze sklonovat celu aplikaciu. Otazka, co je potom deep copy, a co nie je deep copy? Kto to ma rozhodnut? V jazyku to preto nie je, lebo sa nechcu srat s blbostami, ktore si ma osetrit pouzivatel jazyka.

Já bych to deep copy nerozpatlával, už z názvu je zřejmé, že clone není copy, clone by mělo být vytvoření objektu identického obsahu a chování, tj. i identických skládaných objektů, ne jejich kopií, neboli mimo identity se tyto 2 objekty ničím neliší.

Ja tomu rozumiem, len cumil ma tu presviedcal, ze klon by mal byt deep copy.
Klony mezi sebou nesmí mít žádný sdílený stav s vyjímkou prototypů. Jinak to pak opravdu nejsou klony, představ si lidskýho klona se sdílenou slezinou, dává to smysl ?

Jak už tady zaznělo, když má v sobě objekt referenci třeba na window nebo nějaký jiný objekt jehož není přímý majitel, klonování udělá pěknej bordel a musí se udělat ručně.

Není to ale zas tak častý případ a rozhodně to není důvod nedat k dispozici nativní klonovací metodu ...

Slezina nie je dobry priklad, lebo ludsky organizmus nepozna referencie. To by bolo slezinu mozne transplantovat zmenenim referencie na inu slezinu a to dobre nejde.
Jo jasně, neber to doslova, bylo to pouze symbolický připodobnění.


SB

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #106 kdy: 25. 08. 2016, 16:17:12 »
Ja tomu rozumiem, len cumil ma tu presviedcal, ze klon by mal byt deep copy.
Klony mezi sebou nesmí mít žádný sdílený stav s vyjímkou prototypů. Jinak to pak opravdu nejsou klony, představ si lidskýho klona se sdílenou slezinou, dává to smysl ?

Jak už tady zaznělo, když má v sobě objekt referenci třeba na window nebo nějaký jiný objekt jehož není přímý majitel, klonování udělá pěknej bordel a musí se udělat ručně.

Není to ale zas tak častý případ a rozhodně to není důvod nedat k dispozici nativní klonovací metodu ...

Odkazování na jiný objekt ve smyslu asociace (bez vlastnictví - kompozice) je zcela běžné. Podstatné je, proč klonujete originál. U objektů s jedinečnými údaji je to hovadina, tam se používá kopírování s výběrem jednotlivých vlastností.

Pro nativní Clone je podstatné, že je nízkoúrovňové (řeší VM), takže jde naklonovat cokoli, což by jinak u objektů s nepřístupnými vlastnostmi nešlo.

atarist

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #107 kdy: 25. 08. 2016, 16:31:51 »
OT: skutečně celá tato debata pomohla původnímu tazateli? :-)

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #108 kdy: 25. 08. 2016, 17:04:41 »
Ja tomu rozumiem, len cumil ma tu presviedcal, ze klon by mal byt deep copy.
Klony mezi sebou nesmí mít žádný sdílený stav s vyjímkou prototypů. Jinak to pak opravdu nejsou klony, představ si lidskýho klona se sdílenou slezinou, dává to smysl ?

Jak už tady zaznělo, když má v sobě objekt referenci třeba na window nebo nějaký jiný objekt jehož není přímý majitel, klonování udělá pěknej bordel a musí se udělat ručně.

Není to ale zas tak častý případ a rozhodně to není důvod nedat k dispozici nativní klonovací metodu ...

Odkazování na jiný objekt ve smyslu asociace (bez vlastnictví - kompozice) je zcela běžné. Podstatné je, proč klonujete originál. U objektů s jedinečnými údaji je to hovadina, tam se používá kopírování s výběrem jednotlivých vlastností.

Pro nativní Clone je podstatné, že je nízkoúrovňové (řeší VM), takže jde naklonovat cokoli, což by jinak u objektů s nepřístupnými vlastnostmi nešlo.
Tak samozřejmě, používá se to a ostatně, OOP o tom je. Důvod proč chci interface pro klonování je v opačném případě nutnost ručně psát to blbý kopírování slot po slotu, a tolik času fakt nemám. U objektů u kterých počítám s klonováním obvykle (pokud lze) zařídím aby neobsahovali reference někam mimo svůj subgraf, pokud to nejde, musím udělat custom řešení, ...


A krom toho by ještě nativní klonování mohlo nějak kontrolovat zdali objekt neobsahuje referenci někam "mimo" a vyhodit exception.

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #109 kdy: 25. 08. 2016, 17:06:13 »
OT: skutečně celá tato debata pomohla původnímu tazateli? :-)
Tak, to klonování je celkem zajímavý ...


YF

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #110 kdy: 25. 08. 2016, 17:47:46 »
Tak jako minimalne vime ze se muzeme bavit napriklad o klonovani - nicmene abych pravdu tak se ta debata vzdycky zvrhne v silenej proud domenek a nikam moc to nevede - navic si vsichni zacnou na 3ti strance nadavat; tak premyslim jak to udrzet v nejake kondici tu debatu :} tak rekneme ze klonovani: a zajimalo by me odkud teda se bere potreba vubec objekty klonovat? osobne to vidim jako naprosto posledni instanci jak bych resil vytvareni objektu - je to v js normalni a skutecne tak potrebne?

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #111 kdy: 25. 08. 2016, 18:57:42 »
Tak jako minimalne vime ze se muzeme bavit napriklad o klonovani - nicmene abych pravdu tak se ta debata vzdycky zvrhne v silenej proud domenek a nikam moc to nevede - navic si vsichni zacnou na 3ti strance nadavat; tak premyslim jak to udrzet v nejake kondici tu debatu :} tak rekneme ze klonovani: a zajimalo by me odkud teda se bere potreba vubec objekty klonovat? osobne to vidim jako naprosto posledni instanci jak bych resil vytvareni objektu - je to v js normalni a skutecne tak potrebne?
Hele, řeknu ti kde to používám já.

- Mějme systém A.
- V systému A jsou mimo jiné objekty B.
- Do systému A je možné registrovat hooky ( callbacky ).
- Systém A občas v návaznosti na vnitřní stav zavolá některý z callbacku s jedním z interních objektů B a očekává od callbacku odpověď v podobě objektu C.
- Nechci aby user systému A mohl z callbacku zasáhnout do vnitřního stavu A, takže předávaný objekt B naklonuju, a tím pádem si s ním pak už user může dělat co jen chce.

Jindy zase klonování využívám když chci oddělit jednotlivé transformační fáze objektu od sebe třeba proto že někde dál chci použít daný objekt v jednom z mezistavů.

Taky by šlo před-inicializovat objekt a místo tvorby nového objektu jen ten předinicializovaný naklonovat. (defakto factory pattern)

Dále v prototype based OOP se obvykle využívá klonování k tvorbě nových objektů. Respektive objekt získáme tak že naklonujeme prototyp. Dědění se pak dá udělat jako úprava klonu a vydání ho za další prototyp.
Tady se pouštím na tenký led, nejlíp znám JS a to má ten prototypový model maličkato pojatý jinak (o tom také svědčí ignorace klonování), takže tady by bylo fajn kdyby přišel na scénu nějaký guru prototypů.

YF

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #112 kdy: 25. 08. 2016, 19:15:12 »
To je dost divoka hra: nemelo by to uvazovani byt spis nez o stavu spise o prototypu jako predpisu ktery chci dale pouzit k tvorbe instanci ktere maji stejne metody a chovani a to uvazovani o stavu nechat spis na navrh te aplikace? Prijde mi to jednodussi na dalsi uvazovani nad tim - tim ze klonuju se muzu dopustit spousty chyb a nekonzistenci - tim padem je ta struktura potom rekneme dost ... krehka :) Ale sorry - fakt js nerozumim ...

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #113 kdy: 25. 08. 2016, 20:21:54 »
To je dost divoka hra: nemelo by to uvazovani byt spis nez o stavu spise o prototypu jako predpisu ktery chci dale pouzit k tvorbe instanci ktere maji stejne metody a chovani a to uvazovani o stavu nechat spis na navrh te aplikace? Prijde mi to jednodussi na dalsi uvazovani nad tim - tim ze klonuju se muzu dopustit spousty chyb a nekonzistenci - tim padem je ta struktura potom rekneme dost ... krehka :) Ale sorry - fakt js nerozumim ...
Kdyžtak se vyjádři konkrétně k jednotlivejm aplikacím, takhle slytý v jednom to moc nedávám

balki

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #114 kdy: 25. 08. 2016, 20:25:34 »
Nejen !!! Nic se sakra neklonuje, jenom se to frkne do prototypu novýho objektu. Ty data sou kurva sdílený, používat todle na klonování je ve stylu javamana...

To nemusí vadit. Když změníš položku té kopie, tak se nepřepíše v prototypu. Pokud to není zanořená položka v podobjektu.
Good point

Namátkou jen by mě zajímalo jestli to vošéfuje cyklicity korektně.

A co se mi nelíbý, přidává to další level do chainu.

Tam se nemá co zacyklit. Žádná rekurze tam neprobíhá.

Moze tam byt cyklicky graf v referenciach a to sa moze zacyklit. Pekne nazorne to bolo vidiet, ked som pre byvalu firmu robil do RSA plugin ktory vybranu triedu v UML previedol na stromovu strukturu. Riesil som to naivne tak, ze po 4-tej otocke som usudil, ze sa cyklim a dalej som nepokracoval.

balki

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #115 kdy: 25. 08. 2016, 20:30:49 »
idem radsej spat :) Pozeram o prispevok vyssie. Zomg.

gl

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #116 kdy: 25. 08. 2016, 20:40:16 »
Moze tam byt cyklicky graf v referenciach a to sa moze zacyklit. Pekne nazorne to bolo vidiet, ked som pre byvalu firmu robil do RSA plugin ktory vybranu triedu v UML previedol na stromovu strukturu. Riesil som to naivne tak, ze po 4-tej otocke som usudil, ze sa cyklim a dalej som nepokracoval.

v téhle funkci

Kód: [Vybrat]
if (typeof Object.create !== 'function') {
     Object.create = function (o) {
         var F = function () {};
         F.prototype = o;
         return new F();
     };
}

se opravdu nemůže nic zacyklit. Pokud nemám pravdu, prosím o příklad objektu, který tu funkci zacyklí.



balki

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #117 kdy: 25. 08. 2016, 20:51:17 »
Moze tam byt cyklicky graf v referenciach a to sa moze zacyklit. Pekne nazorne to bolo vidiet, ked som pre byvalu firmu robil do RSA plugin ktory vybranu triedu v UML previedol na stromovu strukturu. Riesil som to naivne tak, ze po 4-tej otocke som usudil, ze sa cyklim a dalej som nepokracoval.

v téhle funkci

Kód: [Vybrat]
if (typeof Object.create !== 'function') {
     Object.create = function (o) {
         var F = function () {};
         F.prototype = o;
         return new F();
     };
}

se opravdu nemůže nic zacyklit. Pokud nemám pravdu, prosím o příklad objektu, který tu funkci zacyklí.

Cykli sa mi gebula, spat idem.

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #118 kdy: 25. 08. 2016, 21:55:38 »
Pánové, to Object.create ... je k piči tyvole. Jako copy-on-write klonování to nejde použít. V tomhle vlákně sme došli k závěru že změny v klonu se nedostanou do parenta, jenom naopak. To by někdy šlapalo fajn, ale hovno, ty cyklický reference mi prostě vrtaly furt hlavou a tak sem se to jal vyzkoušet, výsledek je že díky cyklicitám leakne změna stavu v klonu do parenta, takže je to vlastně klonování napiču, přesněji jenom shallow copy, a to není to po čem volám že chci nativně. Kód je dole

Kód: [Vybrat]
var FckinObj = {
  x : { shit: "fuck this" }
};
FckinObj.x.parent = FckinObj;
console.log("FckinObj x: " + FckinObj.x.shit);

var y = Object.create(FckinObj);
y.x.shit = " ERROR BITCH ";

console.log("FckinObj x: " + FckinObj.x.shit);

/* OUTPUT
  "FckinObj x: fuck this"
  "FckinObj x:  ERROR BITCH "
*/

gl

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #119 kdy: 25. 08. 2016, 22:34:16 »
Pánové, to Object.create ... je k piči tyvole. Jako copy-on-write klonování to nejde použít. V tomhle vlákně sme došli k závěru že změny v klonu se nedostanou do parenta, jenom naopak. To by někdy šlapalo fajn, ale hovno, ty cyklický reference mi prostě vrtaly furt hlavou a tak sem se to jal vyzkoušet, výsledek je že díky cyklicitám leakne změna stavu v klonu do parenta, takže je to vlastně klonování napiču, přesněji jenom shallow copy, a to není to po čem volám že chci nativně. Kód je dole

Kód: [Vybrat]
var FckinObj = {
  x : { shit: "fuck this" }
};
FckinObj.x.parent = FckinObj;
console.log("FckinObj x: " + FckinObj.x.shit);

var y = Object.create(FckinObj);
y.x.shit = " ERROR BITCH ";

console.log("FckinObj x: " + FckinObj.x.shit);

/* OUTPUT
  "FckinObj x: fuck this"
  "FckinObj x:  ERROR BITCH "
*/

To má být vtip? Zkus odstranit tu cyklickou referenci. Vypíše to úplně to stejné. y.x.shit vezme x z prototypu. Musel bys nejdřív udělat něco jako y.x = {}, aby se ti vytvořilo x přímo v tom objektu. Create nemůže nahradit deep copy. To tu ani nikdo netvrdil.