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!

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!

TommyCarlier wrote:

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

TommyCarlier said:

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

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

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.

TommyCarlier said:

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

Ion Todirel said:

TommyCarlier said:

*snip*

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

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.

mabster said:

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!

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

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.

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?

Dr Herbie said:

dahat said:

*snip*

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

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.

Dr Herbie said:

dahat said:

*snip*

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

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

EDIT: Oops, thread necromancy.  grr, frindly1000!

frindly1000 said:

Dr Herbie said:

*snip*

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.

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

20.Minutes().Ago()

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

20 minutes ago

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

int? v = element.Value().Eval<int>();

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.

exoteric said:

frindly1000 said:

*snip*

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

 

20.Minutes().Ago()

 

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

 

20 minutes ago

 

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

 

int? v = element.Value().Eval<int>();

 

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.

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.

contextfree said:

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.  

Blend doesnt suit your needs?

Maddus Mattus said:

contextfree said:

*snip*

Blend doesnt suit your needs?

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.

mabster said:

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!

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

Jonwib said:

mabster said:

*snip*

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

I did something like this to copy Jquery.data function

public static class extends{
  public static Dictionary> v = new Dictionary>();
  public static object data(this object o, object key,object val = null)
  {
   if (!v.ContainsKey(o))
   v[o] = new Dictionary();
   if(val!=null)
    return v[o][key];
   v[o][key] = val;
   return val;
  }
}

It won't distinguish between equal simple types, but for complex it works well.

With this you can call any object's data method

F = new Form();

F.data("language","EN");

and inside F you could call

this.data("language") and it would return "EN"

ExceptionDuck said:

Jonwib said:

*snip*

I did something like this to copy Jquery.data function

 

public static class extends{
  public static Dictionary> v = new Dictionary>();
  public static object data(this object o, object key,object val = null)
  {
   if (!v.ContainsKey(o))
   v[o] = new Dictionary();
   if(val!=null)
    return v[o][key];
   v[o][key] = val;
   return val;
  }
}

It won't distinguish between equal simple types, but for complex it works well.

 

With this you can call any object's data method

 

F = new Form();

F.data("language","EN");

 

and inside F you could call

 

this.data("language") and it would return "EN"

Wow, thread Necromancy!

Also, use F# you can extend everything

Property extensions in C# 5.0

// A product type in this sample has a property Name of type String
var product = new Product();

// This will print "Product.Name.IsDirty: False"
Console.WriteLine("Product.Name.IsDurty: {0}", product.Name.IsDirty);

// Now let's try to update product's Name property
product.Name = "C# 4.0 in a Nutshell";

// And now this will print "Product.Name.IsDirty: True"
Console.WriteLine("Product.Name.IsDurty: {0}", product.Name.IsDirty);

// Then when you try to save this product in database, it will be easier for
// Store Repository detect which fields must be saved and which can be skipped
storeRepository.Add(product);
storeRepository.SubmitChanges();

koistya said:

Property extensions in C# 5.0

// A product type in this sample has a property Name of type String
var product = new Product();

// This will print "Product.Name.IsDirty: False"
Console.WriteLine("Product.Name.IsDurty: {0}", product.Name.IsDirty);

// Now let's try to update product's Name property
product.Name = "C# 4.0 in a Nutshell";

// And now this will print "Product.Name.IsDirty: True"
Console.WriteLine("Product.Name.IsDurty: {0}", product.Name.IsDirty);

// Then when you try to save this product in database, it will be easier for
// Store Repository detect which fields must be saved and which can be skipped
storeRepository.Add(product);
storeRepository.SubmitChanges();

That's not the same thing, that's "properties for properties" which is just messed up in my opinion.

I'm perfectly happy with C# 2.0, I only rarely use C# 3.0 (and when I do, it's for Linq).

Wait a sec... this isn't an official blog posting, you're not an employee or someone involved in the language design process. Is this just an example you're proposing or what?

W3bbo said:

koistya said:

*snip*

That's not the same thing, that's "properties for properties" which is just messed up in my opinion.

 

I'm perfectly happy with C# 2.0, I only rarely use C# 3.0 (and when I do, it's for Linq).

 

Wait a sec... this isn't an official blog posting, you're not an employee or someone involved in the language design process. Is this just an example you're proposing or what?

W3bbo, I am trying to make people think and be creative imagining the feature with me

koistya said:

Property extensions in C# 5.0

// A product type in this sample has a property Name of type String
var product = new Product();

// This will print "Product.Name.IsDirty: False"
Console.WriteLine("Product.Name.IsDurty: {0}", product.Name.IsDirty);

// Now let's try to update product's Name property
product.Name = "C# 4.0 in a Nutshell";

// And now this will print "Product.Name.IsDirty: True"
Console.WriteLine("Product.Name.IsDurty: {0}", product.Name.IsDirty);

// Then when you try to save this product in database, it will be easier for
// Store Repository detect which fields must be saved and which can be skipped
storeRepository.Add(product);
storeRepository.SubmitChanges();

> product.Name = "T-Short";
> product.Name.IsDirty

Actually there's nothing prevent you to use "product.Name_IsDirty". That kind of extension makes so little in readability improvement so probably just not worth the effort to change.

cheong said:

koistya said:

*snip*

> product.Name = "T-Short";
> product.Name.IsDirty

Actually there's nothing prevent you to use "product.Name_IsDirty". That kind of extension makes so little in readability improvement so probably just not worth the effort to change.

I can see a potential application with templates:

struct DataProperty<T TData> {

private TData _value;

public event EventHandler PropertyChanged;

public TData Value { get { return _value; } set { _value = value; PropertyChanged(this, EventArgs.Empty); IsDirty = true; }

public bool IsDirty { get; private set; }

}

class SomeBusinessObject {

public DataProperty<String> Name { get; private set; }

}

What do you guys think?

W3bbo said:

cheong said:

*snip*

I can see a potential application with templates:

 

struct DataProperty<T TData> {

 

private TData _value;

public event EventHandler PropertyChanged;

public TData Value { get { return _value; } set { _value = value; PropertyChanged(this, EventArgs.Empty); IsDirty = true; }

public bool IsDirty { get; private set; }

 

}

 

class SomeBusinessObject {

 

public DataProperty<String> Name { get; private set; }

 

}

 

What do you guys think?

1. Doesn't compile
2. Doesn't work because it's a struct (foo.Name.Value = "whatever" would not change the value of Name but that of a temporary copy).
3. Crashes if PropertyChanged is null.

koistya said:

Property extensions in C# 5.0

// A product type in this sample has a property Name of type String
var product = new Product();

// This will print "Product.Name.IsDirty: False"
Console.WriteLine("Product.Name.IsDurty: {0}", product.Name.IsDirty);

// Now let's try to update product's Name property
product.Name = "C# 4.0 in a Nutshell";

// And now this will print "Product.Name.IsDirty: True"
Console.WriteLine("Product.Name.IsDurty: {0}", product.Name.IsDirty);

// Then when you try to save this product in database, it will be easier for
// Store Repository detect which fields must be saved and which can be skipped
storeRepository.Add(product);
storeRepository.SubmitChanges();

what is a "t-short" ?

and yes, it does sound dirty

Minh said:

koistya said:

*snip*

what is a "t-short" ?

 

and yes, it does sound dirty

TommyCarlier said:

Minh said:

*snip*

lmao

spivonious said:

TommyCarlier said:

*snip*

lmao

I ♥ Paint.NET

For instance, we can have:

partial class ClassA 
{ 
    private int total;

    public int Total 
    { 
        get { return total; }
        set { total = value; }
    } 

    public void Add(int value)
    {
        total += value;
    }

    // etc...
}

But why not have something like this:

extension class ClassA 
{ 
    // private int total; // <- The compiler won't allow adding new fields

    public int Total 
    { 
        get { return total; }
        set { total = value; }
    } 

    public void Add(int value)
    {
        total += value;
    }

    // etc...
}

So this proposed extension class is similar to the syntax of a partial class, with some restrictions - notably if you add new fields, the compiler will generate an error. This mechanism has the advantage that there is almost nothing new for the developer to learn in order to use extension properties/methods. The syntax is exactly the same as if you wrote a partial class. In other words, other that just adding the word "extension" in front of the class declaration, the syntax is 100% standard and there is no need to come up with weird declarations at the methods/properties level.

Also, the class/value instance should be passed by ref into the extension properties/methods, so that value types can change fields if they want to (non-withstanding some's belief that value types should be immutable - there are valid cases where you need them to be mutable).

EDIT: For extending structs, you'd probably need to do:

extension struct StructA
{
    //...
}

It's also more DRY - repeating yourself over and over with "this MvcHtmlHelper html" in every single extension method in an extension class isn't useful. You're not going to switch it up and refer to a different object you're extending in that extension class. You're just typing out a lot of extra characters in each method definition to suit an unfortunate design.

12 minutes ago,b9chris wrote

Big +1 to BitFlipper's suggestion for handling all extension-X's. In general Extension Methods are great to have, but the original design is flawed. The existing implementation should be left available for existing code, but the future implementation should be as BitFlipper suggests above. It's straight-forward, it looks more like normal classes, and it doesn't leave you wondering from a design-perspective "But what does an operator look like? But what does a property look like?" which is a sign of its better suitability.

It's also more DRY - repeating yourself over and over with "this MvcHtmlHelper html" in every single extension method in an extension class isn't useful. You're not going to switch it up and refer to a different object you're extending in that extension class. You're just typing out a lot of extra characters in each method definition to suit an unfortunate design.

It's a stab in the dark, but is your last name Rondot, by any chance?

IRT BitFlipper:

You could have extension fields: the compiler would create (behind the scenes) a static Dictionary<TBase,Pair<String,TField>> and do a lookup that way. But I suppose you could do that yourself if you wanted.

Your syntax is nice, but suffers from too-much-typing: often you want to add a single extension method to a whole load of types, or add extension methods to types besides classes and the current syntax is optimised for these scenarios.

Supporting both syntaxes would be better. As for myself, I want to have to explicitly opt-in to extension methods rather than them being implicitly-enabled by importing the namespace they're located in (i.e. you should explicitly import the containing static extension class).

2 hours ago,W3bbo wrote

Supporting both syntaxes would be better. As for myself, I want to have to explicitly opt-in to extension methods rather than them beingimplicitly-enabled by importing the namespace they're located in (i.e. you should explicitly import the containing static extension class).

But that's not how it works. Multiple assemblies can share the same namespace. Using a namespace doesn't "implicitly enable" all the classes across different assemblies that happen to belong to the same namespace. If you don't reference the specific assembly in which the extension methods reside, you're not "opting in" to anything. So "opting in" is more granular than you're making it out to be.

Besides, you're free to seperate all your extension methods into different assemblies, which, in effect, would be like forcing you to import the classes individually. Nobody forces you to put all your extension methods into the same assembly or in the same assembly as the classes that they're extending.