Talk:Extension method

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Seems very similar to Uniform Function Call Syntax. Why not merge the articles? OmerMor (talk) 16:46, 14 September 2015 (UTC)[reply]

New section added[edit]

--Kp1197 (talk) 00:47, 17 October 2012 (UTC)I've added the section on extension method versioning because it's a very essential point of extension methods. The compiler doesn't prevent having extension methods and instance methods with the same names, and this can lead to behavior changes in code. It's something you'd need to know if you came looking for information on extension methods, and that's why I've added it. I'm happy for anybody to edit the wording, which I'm sure isn't perfect. But wholesale deletion without discussion doesn't really fit with the consensus-building model of Wikipedia. --Kyralessa (talk) 22:03, 4 January 2008 (UTC)[reply]

Sure, it is essential but do you really need to demonstrate it? That an instance method will be chosen over an extension method sums it up all. Why do you think readers will not understand it unless presented with an example? Take a look at other articles where naming conflicts are demonstrated. How many of them provides a detailed repro? And you say versioning problem; on what authority can you claim that it is a "problem" for everyone? We just present the facts here, and leave the conclusion whether it is a problem or heavenly boon to the readers.
I am not against inclusion of code, but your text-book example is what I am against. It doesn't feel like I am reading an encyclopedia but rather a beginners book. I will try an edit. --soum talk 13:02, 5 January 2008 (UTC)[reply]
I want to clean up the wording just a bit, but overall I like that edit. It's more concise, and your wording reflects NPOV better than mine did. --Kyralessa (talk) 16:29, 5 January 2008 (UTC)[reply]

Misleading[edit]

The opening sentence suggests that extension methods "add" methods on existing types, and putting bunny ears around it doesn't make it okay. This is totally not the case. Extension methods allow you to invoke static methods on T using the "dot" syntax.

For example --

public static X TransformIntoX<T>(this T t, string someOtherParameter) { ... }

T t = new T();

t.TransformIntoX("quickly");

Which just gets compiled down into the equivalent of:

TransformIntoX(t, "quickly");

String reverse example[edit]

The given code snippet is a good example how you can corrupt Unicode strings. It does not not handle characters outside the Basic Multilingual Plane (supplementary characters or surrogate pairs) correctly. If you reverse such UTF-16 character pairs (surrogates), these characters will be truncated. Further reading: http://code.logos.com/blog/2008/10/how_to_reverse_a_unicode_string_in_c.html —Preceding unsigned comment added by 85.178.92.129 (talk) 17:31, 7 June 2009 (UTC)[reply]

Criticisms/Downsides[edit]

Might be good to have a discussion about the criticisms on Extension Methods, e.g. having new code for existing classes in a different location. Or maybe there are no real downsides? —Preceding unsigned comment added by Jdmwood (talkcontribs) 11:30, 8 June 2009 (UTC)[reply]


Well, not really. That's just a matter of opinion, I believe, like the way one prefers to separate code with comments and little smiley faces. :) Plus, being an optional feature, I can't foresee it causing any harm, can you? That is, except maybe when using some third-party library; but even in such a case, it's just one using statement away. I guess it would take an EXTREMELY picky/OCD person to freak out about that. ;)

If you can somehow find valid criticisms from reputable sources on programming (definitely NOT Sun Microsystems or any for-profit business/competitor of MS, lol), I don't think anyone would object to it. But as it stands, I don't see any rhyme or reason to criticizing extension methods, lol. —Preceding unsigned comment added by 67.142.163.27 (talk) 03:09, 12 January 2010 (UTC)[reply]

You say "a matter of opinion". This article is full of statements that are a matter of opinion. As for "can't foresee it causing any harm", it is extremely common for companies and projects to have standards. Also, note that Microsoft designed C#. As for "rhyme or reason to criticizing", it is also very common to include both advantages and disadvantages of something when describing it. Sam Tomato (talk) 21:32, 12 December 2014 (UTC)[reply]

Similar concepts?[edit]

Why is there no mention of similar concepts in areas outside of the CLI? This article gives the impression that .Net is the only place where you can tack on instance methods at runtime, when in reality it's practically as old as OOP. The Obj-C article mentions other languages in it's categories section; this one should too.

Please clarify option 3 (aggregation) in 'Problem' section[edit]

Please clarify option 3 ("use aggregation instead of inheritance"). I already added links the words 'aggregation' and 'inheritance', but still the use is not indicated. Jacosi (talk) —Preceding undated comment added 15:49, 13 October 2009 (UTC).[reply]


Dead Link[edit]

I removed the link "Code Example", because this link was a dead link. (Link i used Google Chrome)
--Kagurame (talk) 12:29, 16 January 2012 (UTC)[reply]

Programmer's -> programming?[edit]

Shouldn't "application programmer's interfaces" be "application programming interface"? --Mortense (talk) 08:06, 1 June 2013 (UTC)[reply]

Support in programming languages[edit]

Do all the programming languages in the "Support in programming languages" section support extension methods in the same functional manner, or are they actually different features that happen to have "extension" in the name? — Preceding unsigned comment added by Sam Tomato (talkcontribs) 21:17, 12 December 2014 (UTC)[reply]

Object-oriented[edit]

If Extension methods are object-oriented then there must be something that explains what object-oriented concept they support or that they are. Eric Lippert is a principal developer on the C# compiler team. In The Future of C#, Part Two - Fabulous Adventures In Coding he says:

“Extension methods certainly are not object-oriented. They put the code that manipulates the data far away from the code that declares the data, they cannot break encapsulation and talk to the private state of the objects they appear to be methods on, they do not play well with inheritance, and so on.”

Now can someone provide an authoritative justification saying that Extension methods are object-oriented? Note that Microsoft designed the C# language so they are the most authoritative source for that language. Sam Tomato (talk) 21:25, 12 December 2014 (UTC)[reply]

Hi there, I am the Eric Lippert mentioned in the post. Though I appreciate the link to my MSDN blog, there are a few problems here. First, I am not a Principal Developer on the C# compiler team and have not been so since the end of 2012, so if I am to be mentioned at all, I should be identified as a *former* member of the C# compiler team. Second, I do not feel that debating whether or not a particular language feature meets or does not meet a particular bar for OO dogmatists is a good use of Wikipedia. The entire point of the linked article is not that I made a pronouncement that "extension methods are not OO". The point, which has been rather taken out of context here, is that this is an unnecessary debate to have in the first place because the feature was (1) designed to be generally useful for real-world developer needs, and (2) was the most expedient way to get LINQ added to C# 3.0. My request is that the sentence be deleted. Thanks! Ericlippert (talk) 20:49, 28 May 2020 (UTC)[reply]

Extension Methods in Java[edit]

It seems that Java has extension methods also since language level 8.

Here is a stack overflow post:

http://stackoverflow.com/questions/19976487/explicitly-calling-a-default-method-in-java

And this is from the JSL 8:

http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.4.3

Jan Burse (talk) 15:09, 6 October 2015 (UTC)[reply]