2017-04-06 4 views
4

Proのとコンのレコード

type Complex = 
    { 
     real: float; 
     imag: float; 
    } 

または

type Complex = 
    Complex of 
     real: float * 
     imag: float 

のいずれかを使用するのは、私は読みやすさで特に興味を持って、さまざまな状況での取り扱いは何ですか。
パフォーマンスはそれほどではありません。あなたが最初のようなDUタイプを解凍する必要が判別組合(DU)の場合it.real, it.imag

:レコード型の場合

+0

パフォーマンスについては、[]を追加することをお勧めします。 – FuleSnabel

+0

DUは、DUが2つのケース「長方形」と「極」を持つことができるという利点をもたらします。 – FuleSnabel

答えて

4

ヘルパー関数を使用すると、両方のアプローチから同じように得ることができます。

録音

type ComplexRec = 
    { 
     real: float 
     imag: float 
    } 

// Conciseness 
let buildRec(r,i) = 
    { real = r ; imag = i } 

let c = buildRec(1.,5.) 

// Built-in field acces 
c.imag 

連合タイプ

type ComplexUnion = 
    Complex of 
     real: float * imag: float 

// Built-in conciseness 
let c = Complex(1.,5.) 

// Get field - Could be implemented as members for a more OO feel 
let getImag = function 
    Complex(_,i) -> i 

getImag c 

私はunion型の(頻繁に)分解は、パフォーマンスに影響を与える可能性が想像し、私は、件名に何の専門家です。

+1

ニート!だから本質的に言っている: DU:作成するのは簡単だが分解するのは難しい。 rec:作成するのが難しいが解体しやすい (ヘルパーファンクションに頼らない) – 3dGrabber

+0

単一のケースの場合、パフォーマンスは変更しないでください。 – FuleSnabel

3

は、あなたのような両方のフィールドへの即時アクセスを持っているのは、あなたがシンボルit : Complexを宣言したとしましょう:

match it with 
| Complex (real, imag) -> real, imag 

タイプにいくつかの選択肢がある場合は、意味があります。あなたのComplexタイプは少数のケースに分岐しません。ただ一つの可能​​な形状、ケースしか持っていません。

この場合、私は使用法でよりわかりやすいコードを提供するので、私はレコードタイプに賛成です。

+0

シングル・ケース・ユニオンでは、アンパックするために 'match'は必要ないことに注意してください。 – FuleSnabel