Proposal: Extension Methods

[Pragma]

Nick Sabalausky Wrote:

> Maybe it's just an unsubstantiated gut feeling, but that stikes me as either 
> breaking encapsulation, or possibly causing trouble for dynamic linking (ie, 
> one assembly's version of the class has the methods, and another assembly's 
> version doesn't - but then, couldn't that affect C#'s partial classes too? I 
> wonder how they solved it?), or otherwise reducing some of the benefits of 
> strong static typing. 
> 

IMO, yes it does break encapsulation, but it shouldn't disrupt dynamic linking.

The former is really more of a "best practice" kind of thing.  My feeling on that is that a language always generates a wart when it tries to hold too tightly to such things since there's always a case where it doesn't apply.  Perhaps "extension methods" are one of those cases?

As to the latter, dynamic linking, I've played around a lot in this area.  Dynamically linking against anything but an interface is a bad idea for a few reasons; obviously interfaces wouldn't apply with "extension methods".  But if you are coding against a given implementation of a class or struct, then there is no problem since the linked library should have or require the same class or struct.

For dynamic linking and working with classes/structs, the real problem is: do the host program and the dynamic library have access to the same *version* of the class/struct in question?  If not, then there's a mismatch between the binary size and/or vtable layout of the items in question. And that's clearly not a problem that is limited to our hypthotetical "extension methods", so again, there shouldn't be any new technical problems introduced, were they implemented.

- Pragma