That makes it easier to convert regular methods to extension methods, too.

def Get(key, default) as object:
return self[key] if ContainsKey(key) else default

def GetOrSet(key, default) as object:
if ContainsKey(key):
return self[key]
else:
return self[key]=default

def Update(d as IDictionary):
for key in d.Keys:
self[key] = d[key]

Selling points in no particular order:

• it's explicit
• it's easy to have several extension members
• it makes it natural to have extension properties
• you don't have to declare self
• you don't have to keep naming what's extended (just like class
  members don't have to keep naming their class)
• it reuses the same brainspace that knows how to write classes

I prefer the [ExtensionOf(type)] syntax.

in the System.Query.Sequence class:

Extension Methods:
Select
SelectMany
Where
Take
Skip
TakeWhile
SkipWhile
Concat
OrderBy
ThenBy
OrderByDescending
ThenByDescending
Reverse
GroupBy
Distinct
Union
Intersect
Except
ToSequence
ToArray
ToList
ToDictionary
EqualAll
First
FirstOrDefault
ElementAt
Any
All
Count
Sum
Min
Max
Average

Non-Extension Methods:
Range
Repeat

Though they are primarily extension methods, the non-extension methods do belong in the same place.

class A:
___ class B:
______ pass

and that "extend Foo:" is meant to parallel "class Foo:". So if we desire extenions inside classes then allow them there too:

class Sequence:
___ extend IEnumerable:
______ def Select(...)
_________ pass
______ def SelectMany(...)
_________ pass

But don't make me retype IEnumerable 30 times!

extend Foo:
___ _bar as int
___ Bar as int:
______ get:
_________ return _bar
______ set:
_________ assert value>0
_________ _bar = value

The getting and setting of the field _bar would actually be something like the access of a compiler generated Dictionary<[weak] object, Dictionary<string, object>> which maps objects to extension field names to values.

This is just an idea. I'm not proposing that supporting fields be included with BOO-564. I just wanted to show where the "extend Foo:" syntax could take us.

The low level way of defining any extension will simply be applying the existing Extension attribute.

Where before we did:

def DoubleTrouble(self as string):
return self*2

we will now do:

[Extension]
static def DoubleTrouble(s as string):
return s*2

'self' will no longer be allowed as a method parameter by the parser. Remember that this is the low level way.

The high level way will be implemented as a new type of macro. A type declaration macro (MacroTypeDeclaration ast node) and it will be pretty much the extend syntax in the comment above (although field extension support depends on how good the macro will be).

The macro will translate:

extend string:
def DoubleTrouble():
return self*2
IsNullOrEmpty:
get:
return self is null or len(self) == 0

To something like the lower level:

[Extension]
static def DoubleTrouble(extendee as string):
return extendee*2

[Extension]
static IsNullOrEmpty[extendee as string]:
get:
return extendee is null or len(extendee) == 0

which the programmer could have typed in (him|her)self.

I think this will give us:

• a more modular extension implementation;
• a new and powerful type macro facility;
• a syntax which is not hardcoded in the parser and thus can be safely changed/contributed by users through macros;