Call Dispose on anything
-
Can't you make the same argument for
usingas well? Your implementation could ignore types that don't implementIDisposable, for example.Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
Yes, I suppose Duck Typing would do that, maybe for
foreachas well. -
I recognize that extension methods make Intellisense more useful, but a similar result could have been achieved by allowing methods to be tagged as auto-Intellisense, so that they would be listed in the Intellisense pop-up. Typing "textbox1.Text." might include a reverse function in the pop-up list, but selecting it would replace the period after "text" with a right-paren, and insert "StrUtil.Reverse(" before it (if the method took more parameters, it would use a comma rather than a right-paren. Actually, one could leverage Intellisense further by using a double-dot notation for extension methods (since double-dot is not otherwise legitimate, Intellisense would know that when a programmer typed "objectname.." he wanted a list of declared applicable methods. For that matter, that might not have been a bad syntax for extension methods. Conceptually, I wouldn't mind extension methods so much if they were distinct from real ones. Having code change meaning on a rebuild, though, seems like a disaster waiting to happen, unless one always performs full rebuilds whenever anything changes.
I agree with most of this. I like the idea of having the IDE discover utility methods based on some declarative syntax to mark a method as such - and the
Method(this type obj)syntax is fine by me for this purpose. If the IDE modified the code so it instead read Class.Method(obj), using normal static method syntax, it would have been better IMO. However, I don't quite understand your most serious criticism. How could extention methods cause code to change simply because you rebuild? The only code change I can think of that could possibly modify anything would be if a namespace had been replaced by another and this caused some name to resolve to something different from what it did before. But that is true of any members, not just extension methods. I suppose it is slightly more likely to happen with extension methods though, since only the method name and parameter list needs to match in the two namespaces, whereas normal static method syntax would have required the class name to also be the same for the two implementations in order to produce the same effect. -
I agree with most of this. I like the idea of having the IDE discover utility methods based on some declarative syntax to mark a method as such - and the
Method(this type obj)syntax is fine by me for this purpose. If the IDE modified the code so it instead read Class.Method(obj), using normal static method syntax, it would have been better IMO. However, I don't quite understand your most serious criticism. How could extention methods cause code to change simply because you rebuild? The only code change I can think of that could possibly modify anything would be if a namespace had been replaced by another and this caused some name to resolve to something different from what it did before. But that is true of any members, not just extension methods. I suppose it is slightly more likely to happen with extension methods though, since only the method name and parameter list needs to match in the two namespaces, whereas normal static method syntax would have required the class name to also be the same for the two implementations in order to produce the same effect.dojohansen wrote:
The only code change I can think of that could possibly modify anything would be if a namespace had been replaced by another and this caused some name to resolve to something different from what it did before.
Scenario: the version of class "foo" with which a program was written does not have a method named "bar", but an extension method of that name exists and is used within class "boz". Later on, a method named "bar" is added to class "foo". Unless it is rebuilt, class "boz" will use the extension method, but if it is rebuilt it will use the bar() method from class foo. The scenario could not exist without extension methods, since code which tried to use method bar() on an object of class foo would never be able to compile unless or until class foo actually implemented such a method. Unless a functional program used reflection, or else a combination of late binding and error trapping, the addition of a method to a class could not change the program's semantic behavior.
-
dojohansen wrote:
The only code change I can think of that could possibly modify anything would be if a namespace had been replaced by another and this caused some name to resolve to something different from what it did before.
Scenario: the version of class "foo" with which a program was written does not have a method named "bar", but an extension method of that name exists and is used within class "boz". Later on, a method named "bar" is added to class "foo". Unless it is rebuilt, class "boz" will use the extension method, but if it is rebuilt it will use the bar() method from class foo. The scenario could not exist without extension methods, since code which tried to use method bar() on an object of class foo would never be able to compile unless or until class foo actually implemented such a method. Unless a functional program used reflection, or else a combination of late binding and error trapping, the addition of a method to a class could not change the program's semantic behavior.
I don't think your scenario description quite worked out as you intended. After a little reflection I suppose you forgot to mention that boz extends foo..?
supercat9 wrote:
the version of class "foo" with which a program was written does not have a method named "bar", but an extension method of that name exists and is used within class "boz".
Translation:
class foo {}
class boz : foo {
public void method() { this.bar(); }
}We neither know nor care where the extension method, bar, is declared - but it exists and so this builds.
supercat9 wrote:
Later on, a method named "bar" is added to class "foo". Unless it is rebuilt, class "boz" will use the extension method, but if it is rebuilt it will use the bar() method from class foo.
class foo {
protected void bar() { drink(6); Thread.Sleep(TimeSpan.FromHours(11)); } //EDIT: Increased sleep interval :D
}class boz : foo {
public void method() { this.bar(); }
}Indeed it does - if and only if boz extends foo. Also, in this particular example, a more appropriate class name might have been booze. ;)