Neziprotama kļūda

[Wuu]

var alter_send = sendJson;
alter_send[0].input[0].item_batch_nr += ' '+ $(this).attr('name');
alert(sendJson.toSource());
//$.merge(alter_send,sendJson);

Būtībā, gribēju izveidot array kopiju un pievienot viņa kopijai tekstu. Problēma ir tāda, ka nemainot sendJson, bet gan alter_send! Nomainās arī sendJson. Kāpēc?

 

Replika http://jsfiddle.net/zjx6hxwm/

 

Labojama (manā gadījumā) ar

var alter_send = JSON.parse(JSON.stringify(sendJson));

Edited November 11, 2014 by Wuu

[azpage]

Izmanto kopēšanai šo:

var clone = myArray.slice(0);

Javascript mainīgajos glabā saiti uz objektu nevis objekta kopiju.

[Wuu]

Paldies, vari piedāvāt piemēru, kur glabāt vēl vienu saiti uz objektu būtu nepieciešams?

[e-remit]

Paldies, vari piedāvāt piemēru, kur glabāt vēl vienu saiti uz objektu būtu nepieciešams?

Vienkārši runājot, objekti netiek glabāti pašā mainīgajā, bet kaut kur dinamiskajā atmiņā un mainīgajā saglabā tikai saiti uz objektu. Piešķirot jaunam mainīgajam pirmā mainīgā vērtību, jaunajam mainīgajam netiek veidots jauns objekts, bet tiek iedota saite uz to pašu objektu.

Tāpēc arī nevar masīvu pa tiešo nokopēt, bet tikai saiti uz to.

[daGrevis]

Ar šito uzmanīgi. Var nesmuki bagi rasties... :)

 

```

➜ ~ node

> x = []

[]

> foo = function(y) { y.push(42); }

[Function]

> foo(x)

undefined

> x

[ 42 ]

```

[Wuu]

Vienkārši runājot, objekti netiek glabāti pašā mainīgajā, bet kaut kur dinamiskajā atmiņā un mainīgajā saglabā tikai saiti uz objektu. Piešķirot jaunam mainīgajam pirmā mainīgā vērtību, jaunajam mainīgajam netiek veidots jauns objekts, bet tiek iedota saite uz to pašu objektu.

Tāpēc arī nevar masīvu pa tiešo nokopēt, bet tikai saiti uz to.

 

Es saprotu, bet tam ir kāds loģisks izskaidrojums un dzīvē reāls pielietojums, glabāt vēl vienu saiti uz to pašu objektu? Vai arī tas tā ir, un nav ko tur iedziļināties. Man šāda javascript rīcība, liekas gaužām stulba.

[daGrevis]

Tas nav JavaScript specific un saucas passing by reference (otrs ir passing by value). Galvenokārt tiek darīts performancei — nav jākopē un jātaisa pilnīgi jauns objekts.

 

Daļa no jaunajām valodām (salīdzinoši jaunajām) no šī antipatterna un feila dizainā virzās prom ar konceptu sauktu par immutable variables. Tas strādā tā, ka tu nekādīgi nevari izmainīt vērtību mainīgajam — tu vienmēr veido jaunu mainīgo ar kopētu saturu. Varbūt tas ir nedaudz lēnāk (bet tas visticamāk nebūs bottleneck), taču tas atrisina 100 un vienu heisenbagu un ir tā vērts. Kā piemērus šādai pieejai varu minēt Haskell un Clojure.

[Kavacky]

Bagi no references? Antipatterns? Lohiem lohu problēmas.

[daGrevis]

Pats tu loxs. :)

[azpage]

Es saprotu, bet tam ir kāds loģisks izskaidrojums un dzīvē reāls pielietojums, glabāt vēl vienu saiti uz to pašu objektu? Vai arī tas tā ir, un nav ko tur iedziļināties. Man šāda javascript rīcība, liekas gaužām stulba.

 

Tā tas vienkārši ir un nav ko tur iedziļināties, tas tik jāatceras. Esmu pieradis pie tā un bugi tieši šī iemesla dēļ īsti nav.

[daGrevis]

Kad cilvēki nezināja kas ir ritenis un domāja, ka vienīgais veids kā pārnest priekšmetus ir tos nest ar rokām — arī viņi domāja, ka viss ir kārtībā un tas ir pats efektīvākais un labākais veids. Ja tu neesi iedziļinājies un strādajis ar programmēšanas valodām, kurās mainīgais ir immutable, tu nezini, vai mutable values rada bagus, jo neko citu neesi redzējis.

[gurkjis]

Man liekas absurdi dažus megabaitus lielus objektus padot funkcijai kā value. Milzīgs, nevajadzīgs performance overheads. Visdrīzāk, ka pagaidām nesapratu daGrevis domu. Pameklēju pēc "immutable function parameters" - tiešu skaidrojumu neatradu, taču liekas, ka šur tur immutable ir kā opcija uz atsevišķiem mainīgiem vai pielietojuma gadījumiem. 

 

Varbūt vari iemest linku uz info vai google keywords ? 

 

edit: Piemērs: man sistēmā ir objekts A, bet ir kaut kāds process citur, kas ņem A un izsauc tā metodes. Kā gan es bez references to izdarīšu ? To nevar izdarīt. Ja padosi kopiju, tad izmaiņas aizies uz kopiju, nevis tieši A instanci.

Edited November 11, 2014 by gurkjis

[daGrevis]

https://en.wikipedia.org/wiki/Immutable_object

 

https://github.com/facebook/immutable-js

[codez]

Immutable objekti ne tikai atvieglo abstrakciju un darbu ar sarežģītām datu struktūrām paralēlā manierē, bet arī rada zināmus performances efektus.

Piemēram, immutable tree 2 koki var saturēt kopējus elementus, tai pašā laikā no koka abstrakcijas viedokļa būt kā 2 neatkarīgi koki:

 

P.S. Piemēram, Scalā immutable datu struktūras lielākajā daļā darbību ir praktiski tikpat efektīvas kā muttable, bet daļā darbību daudz efektīvākas.

P.P.S. Darbojoties ar immutable objektiem, programmas daļas tiek rakstītas kā funkcijas bez blakus efektiem, kas ļauj šādus algoritmu daudz vieglāk izpildīt paralēlā manierē.

Edited November 11, 2014 by codez

[gurkjis]

Tātad tas ir izdevīgi paralēlajai programmēšanai. Ja es rakstu algoritmu tikai 1 threadam, tad vai immutable pieeja ir tikpat noderīga ? 

 

Pastudēšu.

no wiki:

"If an object is known to be immutable, it can be copied simply by making a copy of a reference to it instead of copying the entire object. Because a reference (typically only the size of a pointer) is usually much smaller than the object itself, this results in memory savings and a potential boost in execution speed."

- šeit teikts, ka immutable objektus nav obligāti jākopē, bet var arī uztvert kā references. Tas nomierina. Tad immutable state attiecīgi nodrošina valoda, ar vai bez references lietošanas.

Edited November 11, 2014 by gurkjis

[codez]

Par to es minēju iepriekšējā postā.

Ja tev ir koks A un tu no tā izveido koku B, kurā ir izmainīti daži elementi, tad koks A un B zem pārsega var saturēt ļoti daudz kopīgu elementu, bet tai pašā laikā no programmas abstrakcijas līmenī uztverti kā 2 pilnīgi neatkarīgi koki.