Coffeehouse Thread

42 posts

C# Extension Properties?

Back to Forum: Coffeehouse
  • User profile image
    ktr

    In C# 3 you can create an extension method like this:

    public static class Extensions {
        public static string ToCamelCase(this string s) {
            // perform action
        }
    }


    Well what about properties? They could act as an indexer would, by using brackets around parameters:

    public static class Extensions {
        public static object Cell[this DataTable t, int row, int column] {
            get { return t.Rows[row][column]; }
           
    set { t.Rows[row][column] = value; }
        }
    }
    // ...
    // usage
    dataTable.Cell[0, 2] = "Hello World";

    That example is simple, but I think it could be a powerful concept. Take, for example, Extended Properties in WPF, which can't be added to the class. Extension Properties would allow a simpler syntax. There are also areas in the .NET Framework where a Property would be better suited but a "GetXXX(type param)" method was used because Parameterized Properties don't exist.

    I dunno, it could end up cluttering the language. What do you think?

  • User profile image
    mabster

    Yeah, I was hoping for extension properties too:

    public static TimeSpan Minutes[this int i]
    {
       getreturn new TimeSpan(0, i, 0); }
    }

    public static DateTime Ago[this TimeSpan ts]
    {
       get { return DateTime.Now.Subtract(ts); }
    }


    So then I could do:

    DateTime d = 20.Minutes.Ago;

    No ugly parentheses!

  • User profile image
    ktr

    Exactly. It would be great to have these to get/set WPF attached properties. For Example, instead of writing this:

    DockPanel.SetDock(btn1, Dock.Left);
    DockPanel.SetDock(btn2, Dock.Left);
    DockPanel.SetDock(btn3, Dock.Left);

    You would write this instead:

    btn1.Dock = btn2.Dock = btn3.Dock = Dock.Left;

    Much cooler Cool

  • User profile image
    esoteric

    mabster wrote:
    Yeah, I was hoping for extension properties too:

    public static TimeSpan Minutes[this int i]
    {
       getreturn new TimeSpan(0, i, 0); }
    }

    public static DateTime Ago[this TimeSpan ts]
    {
       get { return DateTime.Now.Subtract(ts); }
    }


    So then I could do:

    DateTime d = 20.Minutes.Ago;

    No ugly parentheses!


    Sweet. That looks Ruby'ish (not to be mistaken by Rubish). Not that I like Ruby. Smiley

  • User profile image
    Ion Todirel

    mabster wrote:
    Yeah, I was hoping for extension properties too:

    public static TimeSpan Minutes[this int i]
    {
       getreturn new TimeSpan(0, i, 0); }
    }

    public static DateTime Ago[this TimeSpan ts]
    {
       get { return DateTime.Now.Subtract(ts); }
    }


    So then I could do:

    DateTime d = 20.Minutes.Ago;

    No ugly parentheses!
    yeah but its confusing and is too close to an an indexer

  • User profile image
    TommyCarlier

    How is 20.Minutes.Ago more confusing than DateTime.Now.Subtract(new TimeSpan(0, 20, 0))?

  • User profile image
    dcuccia

    TommyCarlier wrote:
    How is 20.Minutes.Ago more confusing than DateTime.Now.Subtract(new TimeSpan(0, 20, 0))?


    lol. Smiley thanks for that.

  • User profile image
    GaryC

    TommyCarlier said:
    How is 20.Minutes.Ago more confusing than DateTime.Now.Subtract(new TimeSpan(0, 20, 0))?
    It's not.  However, there are side effects.  Having the ability to write DateTime.Now.Ago is definitely confusing.  The Ago property would show up on all DateTimes (provided the using statement is there).  The idea is good, though.  Having an int extension property named MinutesAgo seems better.

    I too would have liked to see extension properties.  We have custom properties that we read from the DB and are generating them onto classes.  We are forced to use the ugly GetPropertyname() syntax.

  • User profile image
    littleguru

    GaryC said:
    TommyCarlier said:
    *snip*
    It's not.  However, there are side effects.  Having the ability to write DateTime.Now.Ago is definitely confusing.  The Ago property would show up on all DateTimes (provided the using statement is there).  The idea is good, though.  Having an int extension property named MinutesAgo seems better.

    I too would have liked to see extension properties.  We have custom properties that we read from the DB and are generating them onto classes.  We are forced to use the ugly GetPropertyname() syntax.

    Holy cow... I wanted to reply but this thread is over a year old... and now I did it Sad

  • User profile image
    Sven Groot

    GaryC said:
    TommyCarlier said:
    *snip*
    It's not.  However, there are side effects.  Having the ability to write DateTime.Now.Ago is definitely confusing.  The Ago property would show up on all DateTimes (provided the using statement is there).  The idea is good, though.  Having an int extension property named MinutesAgo seems better.

    I too would have liked to see extension properties.  We have custom properties that we read from the DB and are generating them onto classes.  We are forced to use the ugly GetPropertyname() syntax.
    Actually, as he wrote it the "Ago" property would show up on TimeSpan, not on DateTime, which makes a lot more sense. So you wouldn't actually be able to do DateTime.Now.Ago.

  • User profile image
    Ion Todirel

    TommyCarlier said:
    How is 20.Minutes.Ago more confusing than DateTime.Now.Subtract(new TimeSpan(0, 20, 0))?
    I meant the extension property declaration will be confusing and very close in definition to a indexer

  • User profile image
    Sven Groot

    Ion Todirel said:
    TommyCarlier said:
    *snip*
    I meant the extension property declaration will be confusing and very close in definition to a indexer
    The way I read it, the reason extension properties didn't make it in was because they couldn't reach consensus about a good syntax for declaring them.

  • User profile image
    Ion Todirel

    Sven Groot said:
    Ion Todirel said:
    *snip*
    The way I read it, the reason extension properties didn't make it in was because they couldn't reach consensus about a good syntax for declaring them.
    yep, that's what I wanted to say...

  • User profile image
    SlackmasterK

    mabster said:
    Yeah, I was hoping for extension properties too:

    public static TimeSpan Minutes[this int i]
    {
       getreturn new TimeSpan(0, i, 0); }
    }

    public static DateTime Ago[this TimeSpan ts]
    {
       get { return DateTime.Now.Subtract(ts); }
    }


    So then I could do:

    DateTime d = 20.Minutes.Ago;

    No ugly parentheses!
    Hah.  Reminds me of a query I saw recently.  At my new job, we communicate alot with an ancient DB2 system; someone posted a query like:

    Select * from abc.defg
    where dt = ? - 180 days

    I was like, what? Awesome.

    Then someone showed me that TOP 10 is now FETCH FIRST 10 ROWS ONLY.  And the awe was gone.

    Don't get me started.

  • User profile image
    Andres​Olivares

    I was wondering about this feature as well. Could the syntax look something like this:

    public static class Extensions {
        public static object Cell{
            get(this DataTable t, int row, int column) 
                { return t.Rows[row][column]; }
            set(this DataTable t, int row, int column) 
                { t.Rows[row][column] = value; }
        }
    }

    // usage
    dataTable.Cell[0, 2] = "Hello World";

    The usage would be the same, but the compiler would just have to translate this new syntax and it differs from indexing syntax.

    public static TimeSpan Minutes
    {
       get(this int i) 
        { return new TimeSpan(0, i, 0); }
    }

    public static DateTime Ago
    {
       get(this TimeSpan ts) 
        { return DateTime.Now.Subtract(ts); }
    }

    They still look like properties.

    Andres

  • User profile image
    spivonious

    I'm probably in the minority here, but I think the whole extension methods concept is confusing.  If you want to add a method to a class, then subclass it.  That's why inheritance exists, and it makes a lot more sense to me when I see MyTimeSpan.Ago rather than TimeSpan.Ago, because I might go searching the MSDN for documentation on TimeSpan.Ago only to find it doesn't exist.

  • User profile image
    dahat

    spivonious said:
    I'm probably in the minority here, but I think the whole extension methods concept is confusing.  If you want to add a method to a class, then subclass it.  That's why inheritance exists, and it makes a lot more sense to me when I see MyTimeSpan.Ago rather than TimeSpan.Ago, because I might go searching the MSDN for documentation on TimeSpan.Ago only to find it doesn't exist.
    >  If you want to add a method to a class, then subclass it.

    What if the class you want to add a method to is sealed or worse, is a struct, preventing you from doing just that? Not unlike DateTime, TimeSpan or String?

  • User profile image
    Dr Herbie

    dahat said:
    spivonious said:
    *snip*
    >  If you want to add a method to a class, then subclass it.

    What if the class you want to add a method to is sealed or worse, is a struct, preventing you from doing just that? Not unlike DateTime, TimeSpan or String?
    Well, without the extension method language feature, you'd have to use the decorator pattern. If you only want to add a single method, that's potentially an awful lot of work, which is why I like extensions.

    For me the real strength of extension methods is in adding type-inferenced extension methods to interface, so that classes inheriting that interface automatically get interface-related functionality for free (we discussed this a while ago over on this thread).


    Herbie


Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.