Měnitelnost objektů předávaných odkazem

[novomente]

Dnešní trend nových programovacích jazyků, jako jsou RUST, Nim, Zig, C3 a dalších, je takzvaná immutabilita. Zde mám na mysli neměnnost složitých datových typů - pole, objekty atd.

AI mi na to řekla, že i tyto složité datové typy předávané funkci odkazem, by měli být neměnné (immutable). A namísto nich, že by funkce měla vytvořit kopii oněch datových typů a poslat je zpět jako návratovou hodnotu.

To se však dělá těžko, když jsou datové typy velmi veliké. Zde se například užívá tzv. přepravka. Vezme se malý objekt, pošle se do funkce, která ho vrátí modifikovaný a tato modifikace se pak zapracuje do velikého datového typu. Jenže v některých případech ta přepravka může zpomalovat běh, jako například u herních enginů.

Jak jsou na tom enginy aplikací? Kdy je lepší používat měnitelnost velikého datového typu zevnitř funkce a kdy je lepší používat přepravku, či jinou techniku?

[Reklama]

[a6b]

ja jsem zastance toho aby reference byla immutable a kdyz je mutable, tak aby zmena byla levna.
pokud ma jit o zmenu sloziteho objektu, tak jsem treba v rustu zastancem presunuti (move), objekt se presune do funkce, tam se zmodifikuje a pak se zase presune ven z funkce.

[Kit]

V takovém případě se používají kolekce, které navíc bývají thread-safe.

[RDa]

Velke data se predavaj neprimo - pres handle - odkazem/indexem na nejaky pool pameti.
Jako tohle je "rukojeť", absolutne ale netusim co je to "přepravka"

[listoper]

Me se libi "structural sharing" viz https://clojure.org/reference/data_structures#Collections

[Reklama]

[xyz]

Jen na okraj. Imutability neni trend modernich programovacich jazyku, ale je to koncept stary snad 50 let, ktery prisel z objektove orientovaneho programovani. Jen se tomu rikalo zapouzdreni (encapsulation). K polozkam objektu maji pristup jen metody (zpravy objektu). Jenze pak prisly tzv. POJO a nebo java beans a vsude se k objektum zacaly pridavat gettery a settery a rozlezlo se to.

[Kit]

Jen na okraj. Imutability neni trend modernich programovacich jazyku, ale je to koncept stary snad 50 let, ktery prisel z objektove orientovaneho programovani. Jen se tomu rikalo zapouzdreni (encapsulation). K polozkam objektu maji pristup jen metody (zpravy objektu). Jenze pak prisly tzv. POJO a nebo java beans a vsude se k objektum zacaly pridavat gettery a settery a rozlezlo se to.

Gettery a settery jsou proti principu zapouzdření, protože umožňují manipulaci s jednotlivými atributy.

[Exceptions]

ano, není to moderní novinka, je to spíše odklon od objektového pekla.

Tazatal má správný čich. Na volbě topologie dat v paměti a na disku prostě záleží. Velmi záleží. A musí se to volit velmi pečlivě, v počátku počítačů triky s datovými strukturami a přístupů k nim umožňilo vznik všech těch legendárních programů a her. Dnes už naštěstí nemusíme dělat takové vylomeniny.

[LacconePanda]

například užívá tzv. přepravka.

Dobře, triggernul jste mě. Víte o tom něco ? Pojmy se tu oháníte. Tak se zeptám, je řeč o RefCell a Box<> v Rustu?

[BoneFlute]

Dnešní trend nových programovacích jazyků, jako jsou RUST, Nim, Zig, C3 a dalších, je takzvaná immutabilita. Zde mám na mysli neměnnost složitých datových typů - pole, objekty atd.

AI mi na to řekla, že i tyto složité datové typy předávané funkci odkazem, by měli být neměnné (immutable). A namísto nich, že by funkce měla vytvořit kopii oněch datových typů a poslat je zpět jako návratovou hodnotu.

To se však dělá těžko, když jsou datové typy velmi veliké. Zde se například užívá tzv. přepravka. Vezme se malý objekt, pošle se do funkce, která ho vrátí modifikovaný a tato modifikace se pak zapracuje do velikého datového typu. Jenže v některých případech ta přepravka může zpomalovat běh, jako například u herních enginů.

Jak jsou na tom enginy aplikací? Kdy je lepší používat měnitelnost velikého datového typu zevnitř funkce a kdy je lepší používat přepravku, či jinou techniku?

Návrhový vzor Přepravka slouží k něčemu jinému.

Předávání hodnotou se používá proto, protože je to bezpečnější a kontrolovatelnější, ale logicky dražší.

Předávání odkazem je správný pattern pro předávání velkého objektu. To tak prostě je, je to správně a nic s tím neuděláš.

Přistupuje se k tomu cca třemi způsoby (možná i více)

1/ chceme přehlednost a kontrolu a rezignujeme na výkon - předávání hodnotou

2/ chceme výkon - předávání odkazem, a předává se i vlastnictví (zpopularizoval Rust, ale koncept je to samozřejmě mnohem starší)

3/ Objekt nepředáváme, ale necháme si tou funkcí vrátit co se má na tom objektu udělat (monády/recepty/commandy/operace). Tedy nepředáváme objekt operacím ale do objektu předáváme operace. Toto je taková více architektonická záležitost. Velký datový objekt má na starost omezený kontext kódu, což znamená, že máme větší šanci si to ohlídat, nemusíme předávat celej velkej blob, o různých optimalizačních technikách nemluvě.


PS:

To se však dělá těžko, když jsou datové typy velmi veliké. Zde se například užívá tzv. přepravka. Vezme se malý objekt, pošle se do funkce, která ho vrátí modifikovaný a tato modifikace se pak zapracuje do velikého datového typu. Jenže v některých případech ta přepravka může zpomalovat běh, jako například u herních enginů.

Tohle je tak zmatenej a zašmodrchanej popis, že tam snad není správně ani zájmeno. [peace]