Comment Feed for C# Extension Properties? (Coffeehouse on Channel 9)

Re: Re: C# Extension Properties?

Jonwib — Wed, 07 Oct 2009 08:44:27 GMT

Or you could use VB.NET, where you don't need parentesis after methods ;)

Me to would like extension properties in .net c#; more lika an Aspect oriented aproach

Re: Re: Re: C# Extension Properties?

contextfree — Thu, 24 Sep 2009 17:34:14 GMT

I haven't used it much, but it's a visual designer, right? There's more to WPF than visual design. I'm thinking of setting up dependency properties, etc.

Re: Re: C# Extension Properties?

Maddus Mattus — Thu, 24 Sep 2009 08:02:41 GMT

Blend doesnt suit your needs?

Re: C# Extension Properties?

contextfree — Wed, 23 Sep 2009 17:33:57 GMT

Coding WPF classes in C# sometimes feels like coding COM classes in C++: you have to explicitly provide plumbing that obscures the high-level abstractions. XAML is nicer, but it's both limited in capability and saddled with clunky XML syntax. This is my biggest problem with WPF, an API that in the abstract is very nice, I just wish there were a better view into it ... like JavaFX Script. :P

Re: Re: Re: Re: Re: Re: C# Extension Properties?

Jonathan van de Veen — Wed, 23 Sep 2009 07:44:32 GMT

True, but you can't use that in something like databinding (in WPF or Silverlight at least). Sometimes you just need a property.

Having extension properties would be extremely powerful in a scenario where you use something like LinqToSql in a service, use partial classes there to make properties available in the DataContract and then use some extension properties to format some properties for databinding.

I know I could do the latter with a valueconverter but I find that more troublesome then it needs to be.

Re: Re: Re: Re: Re: C# Extension Properties?

Bent Rasmussen — Mon, 24 Aug 2009 22:04:19 GMT

Still, using a pair of empty ellipses, you can still achieve the same effect, i.e. (for gets, not for sets)

[code language="csharp"]20.Minutes().Ago()[/code]

I believe in Scala you can use any method using infix notation so you might be able to express something like

[code language="scala"]20 minutes ago[/code]

I'm experimenting with using extension methods to achieve null-safe "object-oriented" expressions

[code language="csharp"]int? v = element.Value().Eval<int>();[/code]

Value(), as an extension method over XElement, and Eval as an extension method over object, are both null-safe. If element is null, then the whole expression evaluates to null; if element.Value() is null, then the whole expression evaluates to null; if element.Value().Eval<int>() is not possible (format error or unsupported conversion), then the whole expression evaluates to null.

This property, that one can model null-safety with extension methods is absolutely adorable.

I think the C# field/method/property system is a bit non-uniform now, but it's still very useable and powerful.

Re: Re: Re: Re: C# Extension Properties?

Joe Chung — Mon, 24 Aug 2009 21:15:25 GMT

You cannot subclass a sealed class or a struct to implement the decorator pattern.

EDIT: Oops, thread necromancy. grr, frindly1000!

Re: Re: Re: Re: C# Extension Properties?

Jake — Mon, 24 Aug 2009 20:47:23 GMT

In regards to extension methods being confusing, I agree in that extension methods are extraordinarily powerful and thus have dramatic potential for misuse. However there are a few cases such as adding context specific methods to base objects like object or string or adding methods to a system interface like IList where they are the best way to perform the move.

That being said it is sad that extension properties, which seem to me to be no more or less powerful or appropriate than extension methods were not included simply because an agreement on the declaration syntax could not be reached.

Re: Re: Re: C# Extension Properties?

Herbie Smith — Fri, 30 Jan 2009 18:46:32 GMT

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

Re: Re: C# Extension Properties?

dahat — Fri, 30 Jan 2009 18:14:53 GMT

> 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?

Re: C# Extension Properties?

Scott — Fri, 30 Jan 2009 17:55:54 GMT

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.

Re: C# Extension Properties?

Andres Olivares — Fri, 30 Jan 2009 16:56:12 GMT

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

Re: Re: C# Extension Properties?

SlackmasterK — Wed, 27 Aug 2008 00:28:30 GMT

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.

Re: Re: Re: Re: C# Extension Properties?

Ion Todirel — Mon, 25 Aug 2008 10:59:59 GMT

yep, that's what I wanted to say...

Re: Re: Re: C# Extension Properties?

Sven Groot — Mon, 25 Aug 2008 10:48:51 GMT

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.

Re: Re: C# Extension Properties?

Ion Todirel — Mon, 25 Aug 2008 10:41:30 GMT

I meant the extension property declaration will be confusing and very close in definition to a indexer

Re: Re: Re: C# Extension Properties?

Sven Groot — Mon, 25 Aug 2008 03:00:57 GMT

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.

Re: Re: Re: C# Extension Properties?

Christian Liensberger — Mon, 25 Aug 2008 02:54:51 GMT

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

Re: Re: C# Extension Properties?

GaryC — Mon, 25 Aug 2008 02:44:39 GMT

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.

Re: C# Extension Properties?

dcuccia — Thu, 13 Sep 2007 09:56:06 GMT

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

lol. :) thanks for that.

Re: C# Extension Properties?

Tommy Carlier — Thu, 13 Sep 2007 05:30:19 GMT

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

Re: C# Extension Properties?

Ion Todirel — Wed, 12 Sep 2007 22:36:39 GMT

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

public static TimeSpan Minutes[this int i]
{
get { return 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

Re: C# Extension Properties?

Bent Rasmussen — Wed, 12 Sep 2007 16:23:46 GMT

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

public static TimeSpan Minutes[this int i]
{
get { return 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. :)

Re: C# Extension Properties?

ktr — Wed, 12 Sep 2007 15:20:46 GMT

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 [H]

Re: C# Extension Properties?

Matt Hamilton — Wed, 12 Sep 2007 05:14:52 GMT

Yeah, I was hoping for extension properties too:

public static TimeSpan Minutes[this int i]
{
get { return 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!