You can do some "interesting" things by creating your own operators in C#. At
first I was bitten by the dangerous "that looks cool bug" until a particular
debate unfolded. The problem is the huge gray area involved as to
what looks intuitive to the developer using your API, and what looks confusing.
Obviously you don't want to implement a type conversation operator to convert a
monkey object to a boat object for example. However, it might be OK to convert a HumanAnimalHybrid to a LaserMonkey, but probably not - I'm just playing devils
advocate...
public
class
HumanAnimalHybrid
{ }
public
class
LaserMonkey
{
public
static
explicit
operator
LaserMonkey(HumanAnimalHybrid
hah) {
//..
}
}
class
Program {
static
void
Main(string[] args) {
HumanAnimalHybrid hybrid =
null;
//...
//kinda difficult to understand
LaserMonkey lamemkay = (LaserMonkey)hybrid;
}
}
If you are going to take that route, explicit conversion is might be more
readable than allow the cast to be implicit...
public
class LaserMonkey
{
public static
implicit operator
LaserMonkey(HumanAnimalHybrid
hah) {
//..
}
}
static
void Main(string[]
args) {
HumanAnimalHybrid hybrid =
null;
//...
//quite difficult to understand
LaserMonkey lamemkay = hybrid;
}
Either way, I wouldn't want to write an operator for casting a
HumanAnimalHybrid to a LaserMonkey in my design because it looks ridiculous. The
class names themselves make perfect sense, but the technique just looks wrong to
me. :-)
However, what really spurred this "conversation" was an
interesting post by
Stephen Chu.
Please forgive me Stephen, but I have to debate these kinds of techniques before
I decide whether or not I want to adopt them. Stephen's example is a lot more
realistic, interesting, and fun than my LaserMonkey / HumanAnimalHybrid example.
He points out that you can use implicit operators to do things like this..
State
state = "AZ";
Honestly, when I look at that code, I like this better...
State
state = State.Parse("AZ");
bool valid =
State.TryParse("AZ",
out state);
But...for his Money class example, I like the implicit operator use more than
Money.Parse!
//looks
reasonable IMO
Money money =
299.95;
This is probably because I've seen money as a valid data type in some
languages, but things like a State class don't mentally convert to a string.
Money is probably a decent example of where you might want to create a value
type (struct), much like DateTime. However, DateTime still uses Parse and
TryParse. Again, I'm sure it is just personal preference, but this looks just as
wrong to me as casting a HumanAnimalHybrid to a LaserMonkey...
DateTime
dt = "2/4/2006";
//wrong
State state =
"AZ";
//OK? Not sure
