Records ou Classe [Résolu]

Bonjour à tous,

Dans mon étude du F# (et du paradigme fonctionnel par la même occasion) j'ai du mal à faire la distinction entre record et classe. A part l'héritage je ne vois aucune réelle différence. Alors quand utiliser l'un et pas l'autre ? Il y a-t-il des "règles" ou autre ?

Merci d'avance.
Max.

[gorgonite]

record, si mes souvenirs sont bons, ce sont des éléments du type :

Code :

{champ1 : type1 ; ... ; champN : typeN }

ce ne sont pas des classes très clairement, bien que tu puisses ajouter des méthodes à n'importe quel type F#
tu peux tester... il n'est pas autorisé de les caster vers obj, alors que s'il s'agissait de classes, on pourrait


en gros, ce sont des tuples dont les éléments sont nommés... ça évite d'être dépendant de l'ordre dans lequel cela a été défini

Merci bien pour cette petite précision. Donc si je veux créer un application 3-tiers (je ne sais pas si ça se fait en F#, mais pourquoi pas) j'utilise des objets et pas de records.

Cependant j'ai encore du mal à transposer un application type 3-tiers dans un langage fonctionnel. Si tu avais un exemple ou quelques idée pour m'éclairer, ce serait gentil.

Cordialement,
Max.

[gorgonite]

jamais fait, il te sera difficile de trouver de la doc francophone


commences ici :
http://tomasp.net/blog/aspnet-fsharp-intro.aspx

[LLB]

Envoyé par gorgonite

ce ne sont pas des classes très clairement, bien que tu puisses ajouter des méthodes à n'importe quel type F#
tu peux tester... il n'est pas autorisé de les caster vers obj, alors que s'il s'agissait de classes, on pourrait

Perdu
Tout peut être converti en objet : c'est la fonction box ('a -> obj). Tu as presque raison, quand même : box sur une structure coute un peu, alors que c'est gratuit sur une classe. Mais ce point n'est généralement pas très important (parce qu'on n'est pas sous Java et on possède des generics sans faire du box/unbox 50 fois par seconde).


En gros, le record (ou structure) sert de tuple nommé, comme ça a été dit. Dans un record, tout est public, il n'y a pas d'héritage, etc. Si tu te limites à des choses simples, le record peut être bien adapté (par exemple, un type coordonnée = {x: int; y: int}). Un avantage, c'est que tu peux faire du pattern matching et manipuler les structures plus facilement :

Code F# :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
> type coordonnée = {x: int; y: int};;
type coordonnée = {x: int;
                   y: int;}

> let a = {x = 1; y = 2};;
val a : coordonnée

> {a with y = 3};;
val it : coordonnée = {x = 1;
                       y = 3;}

> let f = function
  | {x = 0} -> 0
  | {x = x; y = 0} -> 2 * x
  | c -> c.x + c.y;;

val f : coordonnée -> int

Les classes permettent de faire des choses plus complexes, mais elles ont tendance à être un peu plus verbeuses.

Il y a aussi des différences de performance, limite les structures à ce qui est simple. Pour en savoir plus, utilise ton moteur de recherche préféré : C# possède aussi cette différence struct / class.

[gorgonite]

Envoyé par LLB

Perdu
Tout peut être converti en objet : c'est la fonction box ('a -> obj).

ben j'ai pas faux... j'ai parlé de cast, pas d'encapsulation

sinon Obj.magic et on peut dire qu'on peut caster n'importe quoi en n'importe quoi... et on obtient un résultat proche de n'importe quoi

[LLB]

Au niveau du langage, on voit pas trop la différence :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
> (5 :> obj);;
val it : obj = 5

> box a;;
val it : obj = {x = 1;
                y = 2;}

> (a :> obj);;
val it : obj = {x = 1;
                y = 2;}

> (upcast a : obj);;
val it : obj = {x = 1;
                y = 2;}

> (Obj.magic a : obj);;
val it : obj = {x = 1;
                y = 2;}

[gorgonite]

Je pensais plus à ceci :

Code :

1
2
3
4
5
6
7
8
> let a = 5 :?> obj;;

  let a = 5 :?> obj;;
  --------^^^^^^^^^^

stdin(4,8): error: FS0016: The type 'int' does not have any proper subtypes and cannot be used as the source of a type test or runtime coercion.
stopped due to error

[LLB]

:> est un upcast statique. int étant un sous-type de obj, 3 :> obj est accepté par le compilateur.

:?> est un downcast dynamique. obj n'étant pas un sous-type de int, 3 :?> obj est refusé à la compilation. En revanche, x :?> int est accepté par le compilateur, si x est de type obj. Une exception est lancée à l'exécution en cas de problème.


L'expression "x :?> obj" n'a pas de sens.
Si x a le type obj, l'expression ne fait rien de plus que renvoyer x.
Dans les autres cas, le compilateur refuse ce code : obj n'est le sous-type de rien. C'est le contraire : tous les types héritent de obj.

[gorgonite]

Envoyé par LLB

L'expression "x > obj" n'a pas de sens.
Si x a le type obj, l'expression ne fait rien de plus que renvoyer x.
Dans les autres cas, le compilateur refuse ce code : obj n'est le sous-type de rien. C'est le contraire : tous les types héritent de obj.

ben justement, ça prouve bien que les types natifs ne dérivent pas de obj, ce qui était le but de la manoeuvre, non ?

[LLB]

Non, tu fais à l'envers.

Tu as montré que le type obj ne dérive pas du type int. Ce qui est normal. Si tu remplaces ton entier par une classe, tu obtiens le même résultat.

Relis mon explication : l'un est un upcast, l'autre un downcast.
Voir aussi :
http://research.microsoft.com/fsharp...p.aspx#Upcasts


PS : si tu n'es pas convaincu, essaie de trouver un exemple où un objet et un entier ne se comportent pas de la même façon.

[gorgonite]

effectivement, en fait leur int est un System.Int32 et donc un objet... vive les types natifs ^^

Merci de vos lumières sur ce sujet.

Cordialement,
Max.