Reputation: 2415
In developing an F# application, I have a type that comprises a property of type Lazy<'T>
.
Apparently, one interesting side effect (pardon the pun) of the way that F# handles the syntactical sugar of properties (as opposed to the C# way) is that the getter and setter of a property may return/accept different types. (At least, Visual Studio is not complaining as I write code that takes advantage of this observation.)
For example, it is advantageous for me to do this:
let lazyValue = lazy 0
member this.Value
with get () =
lazyValue.Value
and set _lazyVal =
lazyValue <- _lazyVal
... such that Value returns an int
, but accepts only a Lazy<int>
.
What I am wondering about are the theoretical, idiomatic, and practical objections to doing things this way. Is this something at which an F# snob would turn up his nose? Is there some functional programming rule of thumb that this (object-oriented implementation) clearly violates? Is this an approach that has been demonstrated to cause problems in large-scale applications? If so, why/how?
Upvotes: 5
Views: 702
Reputation: 43046
Perhaps it is a bug that "Visual Studio is not complaining as [you] write code that takes advantage of this observation". See Using F# Option Type in C#
A comment in the answer to the linked question notes:
From section 8.13.1 of the spec: If a property member has both a getter and a setter, and neither is an indexer, then the signatures of both getter and setter must imply the same property type
Upvotes: 5