Postřehy ohledně architektury JavaScriptu

SB

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #90 kdy: 25. 08. 2016, 11:11:53 »

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ší.


čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #91 kdy: 25. 08. 2016, 11:12:46 »
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á.
Jop, tak už jen ten chain a problem viz nahoře

gl

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #92 kdy: 25. 08. 2016, 11:13:55 »
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.
Jejda, má to problém, pokud v mateřském objektu se změní slot x, zmení se i v klonu pokud slot x do te doby neprepsal, což není garantováno.

To je pravda. Já jsem psal o změnách kopie.

SB

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #93 kdy: 25. 08. 2016, 11:14:17 »
To je marný. To se opravdu sešla parta. Vývojáři, co se zakopali X let zpátky a odmítají se pohnout z místa, jsou k ničemu. Zdůvodnění, že při konjunkci Jupitera se Saturnem může použití Babelu způsobovat problémy, je k smíchu. Když už teď máte problém držet krok s ostatními a ještě jste na svoje ignoranství hrdí, tak se na to radši vyserte.

O konjunkci jsem nic nepsal. Pořád dokola tu prosazuju, jednoduchý, přímočarý a koncepční systém.
Držet krok v čem? Některých držení kroků se totiž rád zdržím.

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #94 kdy: 25. 08. 2016, 11:22:16 »
To je marný. To se opravdu sešla parta. Vývojáři, co se zakopali X let zpátky a odmítají se pohnout z místa, jsou k ničemu. Zdůvodnění, že při konjunkci Jupitera se Saturnem může použití Babelu způsobovat problémy, je k smíchu. Když už teď máte problém držet krok s ostatními a ještě jste na svoje ignoranství hrdí, tak se na to radši vyserte.

O konjunkci jsem nic nepsal. Pořád dokola tu prosazuju, jednoduchý, přímočarý a koncepční systém.
Držet krok v čem? Některých držení kroků se totiž rád zdržím.
Na supermužika nereaguj, pro něj je každej pod 20 starej ...


čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #95 kdy: 25. 08. 2016, 11:23:02 »
To je marný. To se opravdu sešla parta. Vývojáři, co se zakopali X let zpátky a odmítají se pohnout z místa, jsou k ničemu. Zdůvodnění, že při konjunkci Jupitera se Saturnem může použití Babelu způsobovat problémy, je k smíchu. Když už teď máte problém držet krok s ostatními a ještě jste na svoje ignoranství hrdí, tak se na to radši vyserte.

O konjunkci jsem nic nepsal. Pořád dokola tu prosazuju, jednoduchý, přímočarý a koncepční systém.
Držet krok v čem? Některých držení kroků se totiž rád zdržím.
Na supermužika nereaguj, pro něj je každej pod 20 starej ...
Shiiiit nad 20 ...

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #96 kdy: 25. 08. 2016, 11:26:31 »
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.
Jejda, má to problém, pokud v mateřském objektu se změní slot x, zmení se i v klonu pokud slot x do te doby neprepsal, což není garantováno.

To je pravda. Já jsem psal o změnách kopie.
Tak to pak jo, jako klonování to de využít když chceš chránit interní stav (modulu / whatever) a neděláš klony klonů.

Chytrý ale nepoužitelný všude

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #97 kdy: 25. 08. 2016, 11:47:49 »
To se tu zase sešla "parta". Všechno je špatně, go je neobjektové (po 10 minutách studia), žádné knihovny neumožní klonovat objekty, experti na ES6 a přitom neznají ani Object.assign. No comment.

Kdo psal, že je všechno špatně?
Objekt je v Go onen nezapouzdřený struct?
Je klonování klíčovou funkcionalitou objektového systému?
Řeší Object.assign nastavení správného prototypu?

Rádi se necháme poučit (tj. comment).

1. Tohle je subjektivní. Každý si může udělat názor sám.
2. Go není objektové, ale umí chování objektů emulovat. Samozřejmě to nesplňuje požadavky objektových puristů, ale to nesplňuje ani Java nebo Javascript.
3. Nevím, co myslíte objektovým systémem.
4. let copy = Object.assign({ __proto__: obj.__proto__ }, obj);

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #98 kdy: 25. 08. 2016, 12:20:52 »
To se tu zase sešla "parta". Všechno je špatně, go je neobjektové (po 10 minutách studia), žádné knihovny neumožní klonovat objekty, experti na ES6 a přitom neznají ani Object.assign. No comment.

Kdo psal, že je všechno špatně?
Objekt je v Go onen nezapouzdřený struct?
Je klonování klíčovou funkcionalitou objektového systému?
Řeší Object.assign nastavení správného prototypu?

Rádi se necháme poučit (tj. comment).

1. Tohle je subjektivní. Každý si může udělat názor sám.
2. Go není objektové, ale umí chování objektů emulovat. Samozřejmě to nesplňuje požadavky objektových puristů, ale to nesplňuje ani Java nebo Javascript.
3. Nevím, co myslíte objektovým systémem.
4. let copy = Object.assign({ __proto__: obj.__proto__ }, obj);
A co prototypy vnořených objektů? Co deep copy?

balki

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #99 kdy: 25. 08. 2016, 13:40:06 »

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.

SB

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #100 kdy: 25. 08. 2016, 14:29:50 »

Kdo psal, že je všechno špatně?
Objekt je v Go onen nezapouzdřený struct?
Je klonování klíčovou funkcionalitou objektového systému?
Řeší Object.assign nastavení správného prototypu?

Rádi se necháme poučit (tj. comment).

1. Tohle je subjektivní. Každý si může udělat názor sám.
2. Go není objektové, ale umí chování objektů emulovat. Samozřejmě to nesplňuje požadavky objektových puristů, ale to nesplňuje ani Java nebo Javascript.
3. Nevím, co myslíte objektovým systémem.
4. let copy = Object.assign({ __proto__: obj.__proto__ }, obj);

2. Nejde mi o purismus, jen si nechci přidělávat práci - čím lepší je implemetace OOP, tím víc práce mi to ušetří. Java je slabá, ale Javascript je na tom o dost lépe, a o tom to je. :)
3. Myslím zde implementaci OOP, nějaký zazyk.
4. A nešlo by to jednodušeji? mimochodem z dokumentace: "It uses [[Get]] on the source and [[Set]] on the target, so it will invoke getters and setters." To může být na škodu. Neboli nejedná se o nízkoúrovňový klon.

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #101 kdy: 25. 08. 2016, 14:39:12 »

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 ...

čumil

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #102 kdy: 25. 08. 2016, 14:45:23 »

Kdo psal, že je všechno špatně?
Objekt je v Go onen nezapouzdřený struct?
Je klonování klíčovou funkcionalitou objektového systému?
Řeší Object.assign nastavení správného prototypu?

Rádi se necháme poučit (tj. comment).

1. Tohle je subjektivní. Každý si může udělat názor sám.
2. Go není objektové, ale umí chování objektů emulovat. Samozřejmě to nesplňuje požadavky objektových puristů, ale to nesplňuje ani Java nebo Javascript.
3. Nevím, co myslíte objektovým systémem.
4. let copy = Object.assign({ __proto__: obj.__proto__ }, obj);

2. Nejde mi o purismus, jen si nechci přidělávat práci - čím lepší je implemetace OOP, tím víc práce mi to ušetří. Java je slabá, ale Javascript je na tom o dost lépe, a o tom to je. :)
3. Myslím zde implementaci OOP, nějaký zazyk.
4. A nešlo by to jednodušeji? mimochodem z dokumentace: "It uses [[Get]] on the source and [[Set]] on the target, so it will invoke getters and setters." To může být na škodu. Neboli nejedná se o nízkoúrovňový klon.
Tady nejde o to aby to šlo jednodušeji, tady de o to že to nedělá deep copy, sub objekty nejsou naklonovány. Výsledekem je brutální sdílení stavu mezi klonem a originálem. (o prototypech ani nemluvím)

Používá to gettery a settery, pokud by byli tak implementovány, mohly by provádět klonování a tím pádem by assign fungovalo korektně, jenže ty blbý gettery a settery si musíš opět udělat sám, ty default jen překopírujou referenci z jednoho slotu do druhýho.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #103 kdy: 25. 08. 2016, 14:46:41 »

Kdo psal, že je všechno špatně?
Objekt je v Go onen nezapouzdřený struct?
Je klonování klíčovou funkcionalitou objektového systému?
Řeší Object.assign nastavení správného prototypu?

Rádi se necháme poučit (tj. comment).

1. Tohle je subjektivní. Každý si může udělat názor sám.
2. Go není objektové, ale umí chování objektů emulovat. Samozřejmě to nesplňuje požadavky objektových puristů, ale to nesplňuje ani Java nebo Javascript.
3. Nevím, co myslíte objektovým systémem.
4. let copy = Object.assign({ __proto__: obj.__proto__ }, obj);

2. Nejde mi o purismus, jen si nechci přidělávat práci - čím lepší je implemetace OOP, tím víc práce mi to ušetří. Java je slabá, ale Javascript je na tom o dost lépe, a o tom to je. :)
3. Myslím zde implementaci OOP, nějaký zazyk.
4. A nešlo by to jednodušeji? mimochodem z dokumentace: "It uses [[Get]] on the source and [[Set]] on the target, so it will invoke getters and setters." To může být na škodu. Neboli nejedná se o nízkoúrovňový klon.
Ad 2: Go nějak přidělává práci?

balki

Re:Postřehy ohledně architektury JavaScriptu
« Odpověď #104 kdy: 25. 08. 2016, 14:47:22 »

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.