Comments on: C# 3.0: Now with Categories! http://www.friday.com/bbum/2007/01/31/c-30-now-with-categories/ ...so google can index my head. Fri, 19 Mar 2010 16:06:26 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Ken Anderson http://www.friday.com/bbum/2007/01/31/c-30-now-with-categories/comment-page-1/#comment-69275 Ken Anderson Fri, 09 Feb 2007 22:46:36 +0000 http://www.friday.com/bbum/2007/01/31/c-30-now-with-categories/#comment-69275 Bill, that bool return addObjectIfAbsent: method was way back in EOF 2.1 circa 1996 - I know, I found it! (or at least, was one of the finders). I was working at Stratus Computer using OpenStep to build their call tracking system and it took me 3 days of stack and assembly debugging to figure it out...what a nightmare! Bill, that bool return addObjectIfAbsent: method was way back in EOF 2.1 circa 1996 – I know, I found it! (or at least, was one of the finders). I was working at Stratus Computer using OpenStep to build their call tracking system and it took me 3 days of stack and assembly debugging to figure it out…what a nightmare!

]]> By: bbum’s weblog-o-mat » Blog Archive » C# 3.0 Categories Followup http://www.friday.com/bbum/2007/01/31/c-30-now-with-categories/comment-page-1/#comment-65730 bbum’s weblog-o-mat » Blog Archive » C# 3.0 Categories Followup Fri, 02 Feb 2007 06:37:45 +0000 http://www.friday.com/bbum/2007/01/31/c-30-now-with-categories/#comment-65730 [...] A couple of days ago, I posted some observations and questions regarding C# 3.0’s extension methods. [...] [...] A couple of days ago, I posted some observations and questions regarding C# 3.0’s extension methods. [...]

]]> By: Jay Tuley http://www.friday.com/bbum/2007/01/31/c-30-now-with-categories/comment-page-1/#comment-65346 Jay Tuley Thu, 01 Feb 2007 05:38:10 +0000 http://www.friday.com/bbum/2007/01/31/c-30-now-with-categories/#comment-65346 I'm not sure what your point about the System namespace is. For starters, declaring an extension method in System would not be appropriate EVER, also the C# 3.0 spec says that extension methods have a precedences which seem to be help with the problems you are suggestion. The first precedence states that real instance methods take precedence over extension methods -- this may still cause the writer of the extension method trouble, however it's certainly less confusing then the opposite as illustrated in your web objects example. The other precedence is that inner namespaces take precedence over outer namespace -- so if someone else stupidly declares an extension method in system and it's imported, most likely my extension method with the same name is in the namespace i'm using so it will have precedence and thus not cause me grief, but if it's not in my namespace and is just another assembly than it's ambiguous like Nicholas said and you'll probably get an error saying so from the compiler or runtime and you'll just have to reworking your use of the "using" keyword. I’m not sure what your point about the System namespace is. For starters, declaring an extension method in System would not be appropriate EVER, also the C# 3.0 spec says that extension methods have a precedences which seem to be help with the problems you are suggestion. The first precedence states that real instance methods take precedence over extension methods — this may still cause the writer of the extension method trouble, however it’s certainly less confusing then the opposite as illustrated in your web objects example. The other precedence is that inner namespaces take precedence over outer namespace — so if someone else stupidly declares an extension method in system and it’s imported, most likely my extension method with the same name is in the namespace i’m using so it will have precedence and thus not cause me grief, but if it’s not in my namespace and is just another assembly than it’s ambiguous like Nicholas said and you’ll probably get an error saying so from the compiler or runtime and you’ll just have to reworking your use of the “using” keyword.

]]> By: Nicholas Paldino [.NET/C# MVP] http://www.friday.com/bbum/2007/01/31/c-30-now-with-categories/comment-page-1/#comment-65244 Nicholas Paldino [.NET/C# MVP] Wed, 31 Jan 2007 23:23:22 +0000 http://www.friday.com/bbum/2007/01/31/c-30-now-with-categories/#comment-65244 There is nothing wrong per se with the nomenclature that you suggest: <code>public static class MyExtensions extends object {...}</code>. However, it does introduce some issues. The first is that you are limiting the class to be nothing but extensions for object. This might be fine for some people, but too many people would not want that kind of limitation on their classes. Also, it should be noted that you do not need to have your class be declared as <code>static</code> in order to use extension methods. The only requirement for extension methods is that the method be static, and that it use the <code>this</code> qualifier before the type declaration in the parameter list. The <code>static</code> keyword in a class declaration only tells the compiler to make sure that the type has no constructors, and no instance methods. In the case of placing an extension method on <code>Object</code> in the <code>System</code> namespace, obviously, that's can be a huge issue. However, it only occurs when you reference two assemblies that put the same extension method (meaning name and parameter list) in the same namespace and you use the <code>using</code> declaration in the file. In the case of a clash (either with an already existing instance method, or another extension method from another namespace), the compilation should fail, citing that the method is ambiguous (although I have to check the spec for this to be sure). Remember, extension methods are still static methods, so you can still call them in the standard way. They are really just compiler magic/syntactic sugar which was implemented to help make LINQ possible (querying over objects). More specifically, the <code>IEnumerable</code> interface is what is targeted in order to help implement this functionality (along with lambda expressions, anonymous types, and type inference, i.e. the <code>var</code> keyword). Personally, I do not like the syntax with which extension methods are called (and I have been very open with MS about this as well). I believed that at the call site, there should be a different way of calling it, something like <code>obj..MagicDoStuff()</code> or <code>obj->MagicDoStuff()</code> (I prefer the latter for what should be obvious reasons to C++ developers). There is nothing wrong per se with the nomenclature that you suggest: public static class MyExtensions extends object {...}. However, it does introduce some issues. The first is that you are limiting the class to be nothing but extensions for object. This might be fine for some people, but too many people would not want that kind of limitation on their classes.

Also, it should be noted that you do not need to have your class be declared as static in order to use extension methods. The only requirement for extension methods is that the method be static, and that it use the this qualifier before the type declaration in the parameter list. The static keyword in a class declaration only tells the compiler to make sure that the type has no constructors, and no instance methods.

In the case of placing an extension method on Object in the System namespace, obviously, that’s can be a huge issue. However, it only occurs when you reference two assemblies that put the same extension method (meaning name and parameter list) in the same namespace and you use the using declaration in the file.

In the case of a clash (either with an already existing instance method, or another extension method from another namespace), the compilation should fail, citing that the method is ambiguous (although I have to check the spec for this to be sure).

Remember, extension methods are still static methods, so you can still call them in the standard way. They are really just compiler magic/syntactic sugar which was implemented to help make LINQ possible (querying over objects). More specifically, the IEnumerable interface is what is targeted in order to help implement this functionality (along with lambda expressions, anonymous types, and type inference, i.e. the var keyword).

Personally, I do not like the syntax with which extension methods are called (and I have been very open with MS about this as well). I believed that at the call site, there should be a different way of calling it, something like obj..MagicDoStuff() or obj->MagicDoStuff() (I prefer the latter for what should be obvious reasons to C++ developers).

]]> By: Michael Tsai - Blog - C# 3.0: Now with Categories! http://www.friday.com/bbum/2007/01/31/c-30-now-with-categories/comment-page-1/#comment-65216 Michael Tsai - Blog - C# 3.0: Now with Categories! Wed, 31 Jan 2007 21:17:54 +0000 http://www.friday.com/bbum/2007/01/31/c-30-now-with-categories/#comment-65216 [...] Bill Bumgarner: [...] [...] Bill Bumgarner: [...]

]]>