Discussion :

[bumbolol]

Soit la structure 'toto' composée de 'champ1' et de 'champ2', tous les 2 mutables.

Disons que j'ai une fonction 'print_toto' qui m'affiche joliment une variable de type toto.

Si je fais:
let var1 = {champ1 = some_val; champ2 = other_val} in
let var2 = var1 in var2.champ1 <- new_val;
print_toto var1;
print_toto var2;

On peut voir que var1 et var2 sont identiques, quand j'ai modifié le champ1 de var2, ca a aussi modifié celui de var1.

Je voudrais savoir par quoi remplacer 'let var2 = var1 in' pour éviter cela.

Bien sûr, je pourrais remplacer 'let var2 = var1 in var2.champ1 <- new_val' par 'let var2 = {champ1 = var1.champ1; champ2 = new_val} in', seulement en vrai ma structure toto a genre 15 champs, par très pratique quand il y a juste un champ qui doit être modifié dans la nouvelle variable.

Merci d'avance du coup main ^^

[SpiceGuid]

La réponse est dans le manuel du langage.
6.7.3 Operations on data structures/Records :
http://caml.inria.fr/pub/docs/manual-ocaml/expr.html

[LLB]

Remplace :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

let var2 = var1 in var2.champ1 <- new_val;

Par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

let var2 = {var1 with champ1 = new_val}

Et songe à enlever les mutables si tu peux (ce n'est pas très joli).

[bumbolol]

Merci SpiceGuid, même si en tant que grand débutant, la solution au milieu de toute cette page ne pas pas vraiment sauter aux yeux sur le coup ^^.

Merci LLB, j'étais en train de potasser en long la page du manuel, tu m'économises quelques essais-erreurs infructueux ^^.

Même débutant, j'ai bien compris que le mutable c'est pas très élégant dans l'esprit de la prog fonctionnelle, seulement dans le cas présent, la structure provient d'une librairie pour faire du parsing de code, j'ai pas vraiment la possibilité de supprimer les mutables.

Merci encore, ++

[InOCamlWeTrust]

L'esprit des types enregistrement est la même que celui des n-uplets, à l'exception près que les champs sont nommés. On peut donc y avoir accès directement.

Les champs des enregistrements modifiables sont à utiliser uniquement lorsqu'il est impossible de faire autrement.

De façon générale, un bon programme ne devrait jamais utiliser des n-uplets non nommés, sauf pour les traitements intermédiaires ou les structures de données pour lesquelles leur utilisation s'impose d'elle-même. L'idée est généralement que, si il y a besoin de regrouper des données, c'est que ce regroupement est déjà une donnée en elle-même, donc possède un type.

[gasche]

À noter que le coup du "with" n'est qu'une jolie syntaxe pour copier les champs par valeur. Sans l'aide du manuel tu aurais pu trouver la solution suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

let var2 = {champ1 = var1.champ1; champ2 = var1.champ2}

(c'est l'analogue de l'opération pour copier les références : let ref2 = ref !ref1)

De façon générale, un bon programme ne devrait jamais utiliser des n-uplets non nommés, sauf pour les traitements intermédiaires ou les structures de données pour lesquelles leur utilisation s'impose d'elle-même.

Autrement dit, "il ne faut jamais utiliser de n-uplets non nommés, sauf quand il faut".

[bumbolol]

Sans l'aide du manuel tu aurais pu trouver la solution suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

let var2 = {champ1 = var1.champ1; champ2 = var1.champ2}

Comme dis dans le premier post, j'y ai pensé, sauf qu'en pratique je n'ai pas 2 champs mais 15...

(c'est l'analogue de l'opération pour copier les références : let ref2 = ref !ref1)

Je note ^^