Hi,
C# 3.0 extension methods become useful for us. Do we have the similar
concept for extension properties?
Thank you,
Max
26  2810 
On Wed, 23 Jul 2008 15:42:19 -0700, Max2006 <al*******@newsgroup.nospam>
wrote:
C# 3.0 extension methods become useful for us. Do we have the similar
concept for extension properties?
No, I don't think so. But interesting idea. Maybe they're thinking about
it.
Max2006 wrote:
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
On Wed, 23 Jul 2008 17:11:48 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:
[...]
How should the syntax be to distinguish between
a method with no arguments and a property ?
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.
Pete
Peter Duniho wrote:
On Wed, 23 Jul 2008 17:11:48 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:
>How should the syntax be to distinguish between
a method with no arguments and a property ?
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
On Wed, 23 Jul 2008 17:59:45 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:
It will require readers to check the body to see if something is
a method or a property.
Not very nice syntax.
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.
Pete
On Jul 24, 12:22*am, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
C# 3.0 extension methods become useful for us. Do we have the similar *
concept for extension properties?
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
Jon Skeet [C# MVP] wrote:
On Jul 24, 12:22 am, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
>>C# 3.0 extension methods become useful for us. Do we have the similar
concept for extension properties?
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.)
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#)
------------------------------------------------------------------------
Peter Duniho wrote:
On Wed, 23 Jul 2008 17:59:45 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:
>It will require readers to check the body to see if something is
a method or a property.
Not very nice syntax.
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#)
------------------------------------------------------------------------
On Jul 24, 8:53*am, "Frans Bouma [C# MVP]"
<perseus.usenetNOS...@xs4all.nlwrote:
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.
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
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
On Thu, 24 Jul 2008 03:19:24 -0700, Marc Gravell <ma**********@gmail.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
Peter Duniho <Np*********@nnowslpianmk.comwrote:
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.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
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.
On Thu, 24 Jul 2008 17:10:38 -0700, not_a_commie <no********@gmail.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 TestGenericExtensionMethod
{
static class Extensions
{
public static void TestMethod<T>(this T t) where T : TestBase
{
Console.WriteLine("{0}.TestMethod", t.GetType().Name);
}
}
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.ReadLine();
}
}
}
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
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.
On Jul 25, 3:39*pm, not_a_commie <notacom...@gmail.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.Collections.Generic;
using System.IO;
public static class Extensions
{
public static void Something<T(this IList<Tx)
where T : Stream
{
}
}
public class Test
{
static void Main()
{
List<MemoryStreamy = new List<MemoryStream>();
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.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
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();
}
}
}
I should add that changing class Two to inherit from ITwo makes no
difference.
not_a_commie <no********@gmail.comwrote:
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".
--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
On Fri, 25 Jul 2008 11:53:26 -0700, not_a_commie <no********@gmail.com>
wrote:
I should add that changing class Two to inherit from ITwo makes no
difference.
In fact, I think you could have left the Two class out altogether, as well
as made your local variable explicitly typed rather than "var". Those
things just clutter up the example and make it harder to understand the
point ("var" in particular makes it harder to see in an obvious way what
the compiler should be able to assume and what it can't).
That said, I agree that it does look like a compiler bug to me. Though, I
haven't combed the C# spec carefully to be sure, it sure seems like the
compiler is complaining about ambiguity when there is none. See below for
a simpler, more direct example (based on my previous one):
using System;
namespace TestGenericExtensionMethod
{
static class Extensions
{
public static void TestMethod<T>(this T t) where T : TestBase
{
Console.WriteLine("{0}.TestMethod", t.GetType().Name);
}
}
static class ExtensionsTwo
{
public static void TestMethod<T>(this T t) where T : TestBaseTwo
{
Console.WriteLine("{0}.TestMethod", t.GetType().Name);
}
}
class TestBase
{
}
class TestBaseTwo
{
}
class TestDerived : TestBase
{
}
class Program
{
static void Main(string[] args)
{
TestDerived td = new TestDerived();
td.TestMethod(); // <== CS0121
Console.ReadLine();
}
}
}
The full text of the error is:
The call is ambiguous between the following methods or properties:
'TestGenericExtensionMethod.Extensions.TestMethod< TestGenericExtensionMethod.TestDerived
(TestGenericExtensionMethod.TestDerived)' and
'TestGenericExtensionMethod.ExtensionsTwo.TestMeth od<TestGenericExtensionMethod.TestDerived
(TestGenericExtensionMethod.TestDerived)'
Given the constraints, it sure seems like the ExtensionsTwo.TestMethod<T>
method should not be qualifying through type inference as a possible
candidate for the method call.
But as Jon says, just because the compiler has a bug in it, that doesn't
mean that the language doesn't support it. It just means we need the
compiler to be fixed. :)
Pete
I posted this issue on MS Feedback some time ago with ID 336914.
Unfortunately, they didn't seem to anxious to fix it.
The full text of the error is:
* * *The call is ambiguous between the following methods or properties:
* * *'TestGenericExtensionMethod.Extensions.TestMethod <TestGenericExtensionMethod.TestDerived
* * *(TestGenericExtensionMethod.TestDerived)' and
* * *'TestGenericExtensionMethod.ExtensionsTwo.TestMet hod<TestGenericExtensionMethod.TestDerived
* * *(TestGenericExtensionMethod.TestDerived)'
Given the constraints, it sure seems like the ExtensionsTwo.TestMethod<T>*
method should not be qualifying through type inference as a possible *
candidate for the method call.
On Fri, 25 Jul 2008 15:34:58 -0700, not_a_commie <no********@gmail.com>
wrote:
I posted this issue on MS Feedback some time ago with ID 336914.
Unfortunately, they didn't seem to anxious to fix it.
Yes, I see. "By design", with the argument that "overload resolution is
complex enough" without the complication of including constraints.
I'm still not clear on whether that's a language thing, or the compiler
writers deciding it's not worth the trouble. Presumably the former, I'd
think but I (still) haven't had time to check the spec.
Hopefully they'll see the error of their ways in the future. Including
constraints in resolving ambiguities would be useful in a number of
areas. It would even allow overloads that differ only by the constraint
to exist peacefully within the same class.
Anyway, the bottom line here is that it's not that extension methods don't
support constraints. They do. It's just that the resolution of
otherwise-matching signatures isn't supported, which is a problem that
_all_ generic methods share.
Pete
Jon Skeet [C# MVP] wrote:
On Jul 24, 12:22 am, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
>>C# 3.0 extension methods become useful for us. Do we have the similar
concept for extension properties?
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.
If they were thinking about when they did C# 3.0, then believe
they would have picked a different syntax.
Arne
Peter Duniho wrote:
On Wed, 23 Jul 2008 17:59:45 -0700, Arne Vajhøj <ar**@vajhoej.dkwrote:
>It will require readers to check the body to see if something is
a method or a property.
Not very nice syntax.
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
Frans Bouma [C# MVP] wrote:
Jon Skeet [C# MVP] wrote:
>On Jul 24, 12:22 am, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
>>>C# 3.0 extension methods become useful for us. Do we have the
similar concept for extension properties?
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.)
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: WindAndWaves |
last post by:
Hi Gurus
I am just putting my first PHP site together...
One thing that I think it strange is that I do not seem to be able to view
the source. It is almost like the page does not load...
|
by: Carl Ogawa |
last post by:
How do I make .cgi extention work?
I installed ActivePerl 5.8. My CGI scripts work fine with .PL extention but
not .CGI extention although I associated CGI extention as exactly same as PL...
|
by: Tuvas |
last post by:
I am currently writing an extention module that needs to recieve a list
of characters that might vary in size from 0 to 8. This is written as a
list of characters rather than a string because it's...
|
by: Tuvas |
last post by:
I am in the process of writing an extention module, and am coming up
with lots of problems. Perhaps someone could be of use. I keep getting
data that isn't what I'm sending the program. Let me give...
|
by: James Radke |
last post by:
Hello,
I have a multithreaded windows NT service application (vb.net 2003) that I
am working on (my first one), which reads a message queue and creates
multiple threads to perform the processing...
| | |
by: Howard |
last post by:
how do i change the file extention of asp.net file?
ie. from .aspx to .mspx
|
by: ghighi |
last post by:
Hello, Il a downloading a file from a download.aspx page with that
code:
-----------------------------------------------------------------------------------------
string fileName =...
|
by: anandansv |
last post by:
When i try to install .Net2003 in Win2000 Professional is gives an warning message
"Frontpage 2002 server Extention " is not configure.
How to configure that/
|
by: godfather96 |
last post by:
I am using a web control called eXml which is an extention to ms xml web control which supports xslt 2.0
when trying to group elements i receive the following error:
group-by is not a valid...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
