Do we have extention properties in C# 3.0?

[Max2006]

Hi,

C# 3.0 extension methods become useful for us. Do we have the similar
concept for extension properties?

Thank you,
Max

[Marc Gravell]

An extension property therefore should be static, but ... what should

that 'set' do? set a property on arg0?

Yes; as with extension methods the code would explicitely name the arg0
parameter instead of the (explicit or implicit) this in regular instance
members.

Then why not set the property
directly instead of calling this extension property?

Because it might not map to a single property, and we simply want to
encapsulate that logic into a picec of code that is shareable, for
example, over all types (including externals) that implement a
particular interface; to be honest I image "read" extensions properties
would be more common that "write" extension properties, but I can't
think of a good reason to preclude them.

Marc

[Peter Duniho]

On Thu, 24 Jul 2008 03:19:24 -0700, Marc Gravell <ma**********@g mail.com>
wrote:

>An extension property therefore should be static, but ... what should
that 'set' do? set a property on arg0?

Yes; as with extension methods the code would explicitely name the arg0
parameter instead of the (explicit or implicit) this in regular instance
members.

Right. And of course, my example seems to imply that you would be able to
code implicit extension properties, which I'm not actually proposing the
language should support (it could, but the implementation would be so ugly
I don't think it should :) ). I just didn't figure I needed to spell out
the get/set implementations for the purpose of demonstrating a possible
syntax.

>Then why not set the property directly instead of calling this
extension property?

Because it might not map to a single property, and we simply want to
encapsulate that logic into a picec of code that is shareable, for
example, over all types (including externals) that implement a
particular interface; to be honest I image "read" extensions properties
would be more common that "write" extension properties, but I can't
think of a good reason to preclude them.

Me either. I can imagine certain cases, for example, where it would be
more convenient to implement a single property that somehow encapsulates
multiple properties on the extended class. Setting that one property
would have some specific effect on the multiple properties.

As with many things, it's hard to know exactly how something might be used
until you make it available and see how people use it. :)

Pete

[Jon Skeet [C# MVP]]

Peter Duniho <Np*********@nn owslpianmk.comw rote:

Me either. I can imagine certain cases, for example, where it would be
more convenient to implement a single property that somehow encapsulates
multiple properties on the extended class. Setting that one property
would have some specific effect on the multiple properties.

As with many things, it's hard to know exactly how something might be used
until you make it available and see how people use it. :)

Here's a concrete example. I already have a Range<Tclass. It would be
quite nice to give a (readonly - particularly as Range is immutable)
extension property to Range<DateTime> , which retrieved the duration as
a TimeSpan.

Indeed that may end up being one of the primary kinds of use-case:
giving more meaning to one particular closed generic type, but without
needing to add any of the complexities of inheritance.

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[not_a_commie]

My biggest complaint with the extension methods is that they don't
support the 'where' clause. You have to specify the exact type. I'd
rather see support for that before adding support for properties. I'd
also like to see the 'where' clause enhanced to support 'primitive',
meaning types that support these operators: +,-,/,*,%, etc. or maybe
some way to specify operators in the 'where' clause.

[Peter Duniho]

On Thu, 24 Jul 2008 17:10:38 -0700, not_a_commie <no********@gma il.com>
wrote:

My biggest complaint with the extension methods is that they don't
support the 'where' clause. You have to specify the exact type. I'd
rather see support for that before adding support for properties.

Do you mean something like this:

using System;

namespace TestGenericExte nsionMethod
{
static class Extensions
{
public static void TestMethod<T>(t his T t) where T : TestBase
{
Console.WriteLi ne("{0}.TestMet hod", t.GetType().Nam e);
}
}

class TestBase
{
}

class TestDerived : TestBase
{
}

class Program
{
static void Main(string[] args)
{
TestDerived td = new TestDerived();
Object obj = new Object();

td.TestMethod() ; // works fine
// obj.TestMethod( ); // CS0311 error
Console.ReadLin e();
}
}
}

Your wish is granted! :)

I'd
also like to see the 'where' clause enhanced to support 'primitive',
meaning types that support these operators: +,-,/,*,%, etc. or maybe
some way to specify operators in the 'where' clause.

I think lots of people would like to see useful ways to use generics with
operators like that, whether via a constraint or some other mechanism.
Marc Gravell has posted a useful workaround to the current situation. You
should be able to use Google Groups to look back at the archives and find
his articles on the topic.

Maybe that will also appear in a future C#. It's not a trivial problem to
solve (extension properties would be much easier :) ).

Pete

[Marc Gravell]

I'd also like to see the 'where' clause enhanced to support 'primitive',

>meaning types that support these operators: +,-,/,*,%, etc. or maybe
some way to specify operators in the 'where' clause.

As Pete mentions, I've looked at this in the past; a simple answer is
provided here:
http://www.pobox.com/~skeet/csharp/m...operators.html
available as a download from:
http://www.pobox.com/~skeet/csharp/miscutil/

Marc

[not_a_commie]

Your simple case of "<T>(this T t) where T: blah" may work, but the
slightly more complex case of "<T>(this IList<Tlist) where T: blah"
doesn't work properly. The methods show up on all objects.

[Jon Skeet [C# MVP]]

On Jul 25, 3:39*pm, not_a_commie <notacom...@gma il.comwrote:

Your simple case of "<T>(this T t) where T: blah" may work, but the
slightly more complex case of "<T>(this IList<Tlist) where T: blah"
doesn't work properly. The methods show up on all objects.

That's not happening for me. Could you give a short but complete
example? Here's one from me:

using System;
using System.Collecti ons.Generic;
using System.IO;

public static class Extensions
{
public static void Something<T(thi s IList<Tx)
where T : Stream
{
}
}

public class Test
{
static void Main()
{
List<MemoryStre amy = new List<MemoryStre am>();
y.Something();

List<objectz = new List<object>();
z.Something();
}
}

The z.Something() line fails to compile, with this error:

<quote>
Error 1 The type 'object' cannot be used as type parameter 'T' in the
generic type or method
Extensions.Some thing<T>(System .Collections.Ge neric.IList<T>) '. There
is no implicit reference conversion from 'object' to
System.IO.Strea m'. C:\Documents and Settings\jonske et\My Documents
\Visual Studio 2008\Projects\T est\Test\Progra m.cs 21 9 Test
</quote>

Jon

[not_a_commie]

Here's my test case. It gives an 'ambiguous call' error when it is
clearly not ambiguous.

namespace TestExtensions
{
public interface IOne
{
int Int { get; set; }
}

public class One: IOne
{
public int Int { get; set; }
}

public interface ITwo
{
int Int { get; set; }
}

public class Two : IOne
{
public int Int { get; set; }
}

public static class ExtensionsOne
{
public static void AddFive<T>(this T obj) where T : One
{
obj.Int += 5;
}
}

public static class ExtensionsTwo
{
public static void AddFive<T>(this T obj) where T : Two
{
obj.Int += 5;
}
}

class Program
{
public static void Main(string[] args)
{
var one = new One();
one.AddFive();
}
}
}

[not_a_commie]

I should add that changing class Two to inherit from ITwo makes no
difference.