Talk:Extension method

Latest comment: 4 years ago by Ericlippert in topic Object-oriented

Merge With Uniform Function Call Syntax?

edit

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


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