exoteric said:

ramooon said:

*snip*

Interesting idea. It looks like a more complete/holistic/uniform approach to type extension, kudos. It is reminiscent of partial classes, except not exclusive for classes. Now I wonder: if you have a partial class A and another partial class B in two distinct namespaces and say you have a simple console program and the console program imports partial class A; will partial class B then also implicitly be used or only if you explicitly import that namespace? In the latter case the partial class construct looks pretty darned close to what you want, except partial to classes, so to speak. Hindsight is great.

 

As for public/private, private is probably a sign of imperativeness because in an imperative setting you want to be careful about who's modifying your object using your special helper methods whereas when constructing new objects it's not really that big of an issue and this default looks wrong for a mostly-declarative world (or functional if you will). This will also save lots of code having to explicitly declare public all over. Well... too late for C#, that ship sailed long ago.

Well, I'm not sure to understand what you said but the extensions would be available only if you import the right namespaces (ie. exactly the same behavior as the current syntax). The main benefit over partial classes is that it does not require  the 'partial' keyword at the declaration site and it is not limited to classes therefore basically everything is extensible by default What I didn't realize is that the partial keyword would become totally useless o_O ... right ?

BTW Here's what I would like to see in future C# releases:

- Contracts: Spec# contracts built-in the language (with the bang non-null operator)

- Metaprogramming: a way to have user-defined keywords and syntax (ie.  a 'keyword' keyword and so on)

- Immutablilty and Purity keywords

- Some more declarative and lazy stuffs -- I absolutely love LINQ

Another idea, but IDE specific:

I wonder why although the IDE is now WPF based, it is still limited to classic characters ?

For example if I type something like "-->" I would like the IDE to replace it with a real arrow.

This would allow custom symbols to be used in modern languages...

exoteric said:

Ion Todirel said:

*snip*

To illustrate

public struct STuple<a>
{
    private readonly a x;
    public a Some
    {
        get { return x; }
    }
    public a this[int index]
    {
        get
        {
            if (index != 0)
                throw new IndexOutOfRangeException();
            else
                return x;
        }
    }
    public IEnumerator<a> GetEnumerator()
    {
        yield return Some;
    }
    public static int Index
    {
        get { return 0; }
    }
    public static int Length
    {
        get { return Index + 1; }
    }
    public STuple(a a)
    {
        x = a;
    }
}
public struct STuple<a, b>
{
    private readonly a x;
    private readonly STuple<b> s;
    public a Some
    {
        get { return x; }
    }
    public STuple<b> Rest
    {
        get { return s; }
    }
    public dynamic this[int index]
    {
        get
        {
            if (index > Index || index < 0)
                throw new IndexOutOfRangeException();
            else
                return index == Index
                    ? Some as dynamic
                    : Rest.Some as dynamic;
        }
    }
    public IEnumerator<dynamic> GetEnumerator()
    {
        yield return Some;
        yield return Rest.Some;
    }
    public static int Index
    {
        // C# forbids: (Rest.Index + 1)
        get { return 1; }
    }
    public static int Length
    {
        get { return Index + 1; }
    }
    public STuple(a a, b b)
    {
        x = a;
        s = new STuple<b>(b);
    }
}

Example

var a = new STuple<int>(3);
var b = new STuple<int,int>(1,2);
foreach (var x in a)
    Console.WriteLine(x);
foreach (object x in b)
    Console.WriteLine(x);
Console.ReadKey();

If we could somehow express a version of GetEnumerator that only applies to a homogeneous (s)tuple, meaning (s)tuple where all type parameters are equal, then there would be no need for a dynamic formulation, esp. as this is statically known.

public static class STupleExtensions
{
    public static IEnumerator<a> GetEnumerator<a>(this STuple<a, a> s)
    {
        yield return s.Some;
        yield return s.Rest.Some;
    }
}

I realize though that this kind of trickery is probably not very high on any wishlist heh

I would love to see a way to extend types beyond that awkward "first-parameter-with-this-modifier" trick.

For example this natural syntax would be awesome:

// 'class', 'struct', 'interface' or 'enum' keywords
// are useless here since the type already exists
public extension TypeToExtend
{	
     // 'public' modifier is useless here, as in any interface declaration
     void ExtensionMethod()
     {
          // the 'this' keyword is available here
          ...
     }

     static void StaticExtensionMethod()
     {
          // the 'this' keyword is NOT available here, as in any static method
          ...
     }

     void ExtensionProperty { get; set; }
}

As you can see it would allow "extension properties" and "extension static methods".

You could even have "extension constructors", "extension events" and so on...

Everything you could imagine to extend !