C# Extension Properties?

TommyCarlier said:

Minh said:

*snip*

lmao

spivonious said:

TommyCarlier said:

*snip*

lmao

I ♥ Paint.NET

Are we back on this topic again? Well, in that case I'd like to mention an idea I had that does away with all the arguments about "can't come up with a decent syntax for extension properties" argument. Instead of working at the property/method level, why not wrap the whole thing into a special type of extension class?

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
{
    //...
}

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.

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.