Call Dispose on anything
-
Luc Pattyn wrote:
I would not want to write string s=new string(new char[]{'H','e','l','l','o'}; !
I don't see why you'd have to.
Luc Pattyn wrote:
foreach
Oh, yeah, that was the other one, but it should work too.
How about
lockthen?Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
I just looked at the auto-generated code, and it seems that there is a #Region created with a parameterless Dispose() which calls Dispose(True) and SuppressFinalize, but does not actually contain a finalizer (though if a finalizer is created, it's supposed to call Dispose(False)). That seems like a good approach to doing things. Your comment about minimizing the actual Finalizable "footprint" is a good one. Among other things, if an object controls multiple unmanaged objects, splitting things up would allow separate finalizers for each. BTW, are there any sorts of well-designed objects which use finalizers but do not implement iDisposable? I still find it strange that all objects inherit Finalize, but not Dispose.
supercat9 wrote:
I still find it strange that all objects inherit Finalize, but not Dispose.
I think it's because the CLR calls Finalize, but developers are supposed to call Dispose. The CLR doesn't consider an object to be finalizable if it doesn't override the implemenation derived from Object. If all types have Dispose, it'd be hard for developers to figure out the types for which they'll have to call Dispose.
supercat9 wrote:
BTW, are there any sorts of well-designed objects which use finalizers but do not implement iDisposable?
That'd be a bug, wouldn't it? The object holds resources that need to be released, but it doesn't allow the user to release them early.
Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
How about
lockthen?Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
I don't think that relies specifically on anything in .net; it could be implemented differently.
-
I don't think that relies specifically on anything in .net; it could be implemented differently.
Well, it calls
Monitor.EnterandMonitor.Exit, and they are specific types in the .NET BCL.Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
Well, it calls
Monitor.EnterandMonitor.Exit, and they are specific types in the .NET BCL.Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
That's just implementation; a different implementation could do something different.
-
That's just implementation; a different implementation could do something different.
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
-
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. ;)