Jump to content
php.lv forumi
  • 0

Neziprotama kļūda


Wuu

Question

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 by Wuu
Link to comment
Share on other sites

Recommended Posts

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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 by gurkjis
Link to comment
Share on other sites

  • 0

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:

binary_tree_after_insert.png

 

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 by codez
Link to comment
Share on other sites

  • 0

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 by gurkjis
Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...