7

Check the code bellow:

class Money
{
    public Money(decimal amount)
    {
        Amount = amount;
    }

    public decimal Amount { get; set; }

    public static implicit operator decimal(Money money)
    {
        return money.Amount;
    }

    public static explicit operator int(Money money)
    {
        return (int)money.Amount;
    }
}

I don't understand how it would be useful in my code, couldn't I just do a method like:

public static int returnIntValueFrom(Money money)
{
    return (int)money.Amount;
}

Wouldn't it be easier and clearer to implement?

Marcel James
  • 834
  • 11
  • 20
  • 5
    What do you think allows you to write things like `return (int)money.Amount;` in your code? – mbeckish Aug 12 '13 at 23:25
  • Thats a sample found on a Microsfot training kit,(Exam Ref 70-483 Programming in C#, Wouter de Kort, O´Reilly, 2013 (Page 110 CHAPTER 2 Create and use types)) – Marcel James Aug 12 '13 at 23:37
  • @WilnerAvila - Once you get to 20 reputation, you can always ask these types of "I don't understand" questions in the [c# chat room](http://chat.stackoverflow.com/rooms/7/c). It is a better format for quick explanations than SO is. – Travis J Aug 12 '13 at 23:42
  • @TravisJ Oh thanks, I did not know about it! – Marcel James Aug 12 '13 at 23:47
  • @WilnerAvila: it's a so called syntatic sugar. It's clearer to do 10+(Money)33 than 10+returnInvValueFrom(33) – Luis Filipe Aug 12 '13 at 23:49
  • @WilnerAvila - My point was that don't you think `return (int)money.Amount` is easier and clearer to use than `return Decimal.returnIntValueFrom(money.Amount)` ? – mbeckish Aug 13 '13 at 00:32

1 Answers1

6

This is done to allow for money to be added to other money. Without that piece of code, this would cause a compiler error, "Operator '+' cannot be applied to operands of type 'Money' and 'int'"

Money money = new Money(5.35m);
decimal net = money + 6;

With the casting operator present it allows these types of conversions to be made without throwing an exception. It can assist in readability and allow for polymorphism where different currencies could implement their own types of casts for example.

Travis J
  • 81,153
  • 41
  • 202
  • 273
  • While your main point is correct, it wouldn't actually throw an exception, unless that's how you refer to compile-time errors. – 500 - Internal Server Error Aug 12 '13 at 23:42
  • @500-InternalServerError - You are correct, it was a compile time error and I will edit my answer. – Travis J Aug 12 '13 at 23:43
  • This is awesome, I never knew the implicit cast operator allowed you to do this kind of thing. – McGarnagle Aug 12 '13 at 23:59
  • 2
    Implicit casts are inherently bad (here's a [good article to read](http://netvignettes.wordpress.com/2011/04/24/implicit-conversion-operators-are-bad/) that reasons about it) and you should avoid them completely instead of suggesting them. Instead of defining an implicit cast operator, you'll do better to implement the `+` operator - `public static Money operator+(Money money, decimal amount)`. That makes your intend clearer. – Nikola Dimitroff Aug 13 '13 at 00:18
  • @NikolaDimitroff: Implicit operators are bad on reference types which encapsulate identity rather than value. I would posit that for an implicit operator from T to U to really be good, then given `T t; U u1,u2;` `(T)u1 == u2` should either refuse to compile, throw an exception, or test for equality between `u1` and `u2`. Note that .NET has numerous conversions for which the code would compile and run without throwing exceptions, but would not properly test equality. – supercat Sep 02 '13 at 21:48
  • @supercat I've read [that article, which Nikola had posted](http://netvignettes.wordpress.com/2011/04/24/implicit-conversion-operators-are-bad/). My thought (for now) is that implicit conversions introduce semantic problems when they return reference types, but an implicit conversion doesn't introduce a semantic problem when it returns a value type. – Nick Alexeev Sep 30 '14 at 22:18