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

 

[Arne Vajhøj]

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

No.

And there is a syntax problem.

Properties are distinguished from methods by the fact that they
do not have an argument list.

The object being extended is passed as an extra argument.

How should the syntax be to distinguish between
a method with no arguments and a property ?

Arne

 

[Arne Vajhøj]

Syntax for an extension property:

public int MyProperty(this SomeClass arg0)
{
get;
set;
}

Just because properties as declared now don't include an argument list,
that doesn't mean they couldn't. There's enough other information in
the declaration block to distinguish a property from a method, I believe.

No doubt there are other valid ways to allow the declaration of an
extension property, but the above seems most straightforward and
consistent to me.

It will require readers to check the body to see if something is
a method or a property.

Not very nice syntax.

Arne

 

[Jon Skeet [C# MVP]]

No, I don't think so.  But interesting idea.  Maybe they're thinking about  
it.

It's definitely been considered. I don't know whether it's actually
going to be in C# 4 or not. (I'm looking forward to a first proper
peek at C# 4, whenever that happens. I expect it to be a much smaller
set of changes than either 2 or 3 though.)

Jon

 

[Frans Bouma [C# MVP]]

It's definitely been considered. I don't know whether it's actually
going to be in C# 4 or not. (I'm looking forward to a first proper
peek at C# 4, whenever that happens. I expect it to be a much smaller
set of changes than either 2 or 3 though.)

I think the C# team, IF they implement extension properties, should
take that famous step back and look again at what the REAL reason is
people want extension properties (as they represent state): AOP. So they
should use their influence to turn the CLR team over to implement AOP at
the CLR level once and for all.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Frans Bouma [C# MVP]]

I don't personally see the big deal. But if you don't like that, how
about this:

public int MyProperty
{
this SomeClass arg0;
get;
set;
}

Or provide your own suggestion. Complaining that it can't be done
because of a syntax problem is dumb. That's what we pay the language
designers the big bucks for. Let them figure it out and come up with
something that is reasonably elegant and makes life easy for the
compiler writer, if that's so important.

Heh

I think this syntax is parsable, the other is very hard to do, as it
requires a looooooong look ahead.

Nevertheless, there's a practical problem as well: Extension methods
are static, i.e. don't have state, they work on the object passed in.
However, a property represents state, on the object they're a part of.
An extension property therefore should be static, but ... what should
that 'set' do? set a property on arg0? Then why not set the property
directly instead of calling this extension property?

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Jon Skeet [C# MVP]]

        I think the C# team, IF they implement extension properties, should
take that famous step back and look again at what the REAL reason is
people want extension properties (as they represent state): AOP. So they
should use their influence to turn the CLR team over to implement AOP at
the CLR level once and for all.

I don't immediately see the AOP connection, but I'm sure you're right
- could you elaborate?

I see extension properties as a way of providing different views on
existing state.

Jon

 

[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

 

[Jon Skeet [C# MVP]]

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<T> class. 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.

 

[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.

 

[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/miscutil/usage/genericoperators.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<T> list) where T: blah"
doesn't work properly. The methods show up on all objects.

 

[Jon Skeet [C# MVP]]

Your simple case of "<T>(this T t) where T: blah" may work, but the
slightly more complex case of "<T>(this IList<T> list) 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.Collections.Generic;
using System.IO;

public static class Extensions
{
public static void Something<T> (this IList<T> x)
where T : Stream
{
}
}

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

List<object> z = 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.Something<T>(System.Collections.Generic.IList<T>)'. There
is no implicit reference conversion from 'object' to
System.IO.Stream'. C:\Documents and Settings\jonskeet\My Documents
\Visual Studio 2008\Projects\Test\Test\Program.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.

 

[Jon Skeet [C# MVP]]

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

That looks like a compiler bug to me. I suggest you report it on
connect.microsoft.com.

However, that's one particular case - I think it's a long way from that
to your earlier claim that "extension methods don't support the where
clause".

 

[not_a_commie]

I posted this issue on MS Feedback some time ago with ID 336914.
Unfortunately, they didn't seem to anxious to fix it.

 

[Arne Vajhøj]

It's definitely been considered. I don't know whether it's actually
going to be in C# 4 or not.

If they were thinking about when they did C# 3.0, then believe
they would have picked a different syntax.

Arne

 

[Arne Vajhøj]

I don't personally see the big deal.

Code should be understandable reading sequentially.

But if you don't like that, how
about this:

public int MyProperty
{
this SomeClass arg0;
get;
set;
}

Better. But still not very good. The signature does not tell what it is.

Or provide your own suggestion. Complaining that it can't be done
because of a syntax problem is dumb.

I think it is only in your imagination someone has said that
it can not be done.

Of course it can be done. But there is a problem finding a good
syntax that is consistent with the C# 3.0 extension methods.

Arne

 

[Arne Vajhøj]

I think the C# team, IF they implement extension properties, should
take that famous step back and look again at what the REAL reason is
people want extension properties (as they represent state): AOP. So they
should use their influence to turn the CLR team over to implement AOP at
the CLR level once and for all.

Interesting thought.

But what would that be more specifically ?

Arne