Records ou Classe

Version imprimable

05/08/2008, 17h28

Records ou Classe

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.
05/08/2008, 17h36
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 :)
05/08/2008, 18h52

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.
05/08/2008, 19h33
gorgonite

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

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

Citation:

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:

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.

05/08/2008, 21h23
gorgonite

Citation:

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 :P

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 :aie:

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;}

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

05/08/2008, 23h02
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.
05/08/2008, 23h20
gorgonite

Citation:

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 ?
05/08/2008, 23h41
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.
06/08/2008, 08h56
gorgonite

effectivement, en fait leur int est un System.Int32 et donc un objet... vive les types natifs ^^
06/08/2008, 14h04

Merci de vos lumières sur ce sujet.

Cordialement,
Max.