Yet ANOTHER C# language enhancement - this_method()

Tags: .NET, C#

Sunday, June 3, 2007 11:34:24 AM

This one was suggested by a coworker leery of accidental recursion. Too many people aren't used to thinking in terms of recursion and will miss a recursive call inside a method and accidently start an infinite loop, or miss the meaning of a method thinking it's an overload call.

His idea - a language keyword that specifies a call to the CURRENT method, again. He originally suggested the recurse keyword to be totally explicit. I thought of this_method as another substitute that's similar to the existing this keyword.

Now, I know the C# language team don't want to burden the language with too many keywords since it's harder to parse, both by the compiler and the programmer. This certainly shouldn't be a top-priority on the feature list. However, considering C#'s design goal of explicitness, I figure it might make it in.

Any comments/ideas/opinions?

21 Comments

  • Avner Kashtan said

    Yeah, I know. The coworker in question got the idea from Resharper. Still, tool support isn't the same as a language feature. In the last couple of years I tended to drift between many environments and many projects, staying only weeks or months in each (contractor/consultant, not getting fired every time. :) and I grew wary of relying on tools, especially if they're commercial tools I can't easily take with me from place to place.

  • Ori Folger said

    What would happen with mutually recursive calls? Method A calls method B which calls method B again. This indirection can be extrapolated to many levels, of course. With virtual methods, this indirection might not even be detectable at compile time.

  • Avner Kashtan said

    Raymond: Good point. We're gaining explicitness on one end (explicitly stating that we're recursing) while losing explicitness on the other (not explicitly saying what code we're calling). I can't think of many situations in which I will copy recursive code into a non-recursive function, but I'm sure they exist - like in Ori's point, where I take a recursive method and split it into two mutually recursive ones. Still, it's an idea. Not a perfect one, but maybe it will spawn others.

  • Wim Hollebrandse said

    No way. The language spec should not be burdened with silliness like that. If you code stuff and you need a compiler to enforce you of how to call a method recursively, you're simply out of your depth. Anyway - when experienced programmers accidentally cause a recursive call, they spot it at run-time when testing once you run into a StackOverFlowException. More keywords only pollutes the cleanliness of the language that is C#.

  • Avner Kashtan said

    Omer: As I said, explicitness. To be able to read code and understand instantly what it does, including any subtleties.

  • Omer van Kloeten said

    I don't know - inserting new keywords into the language just to describe patterns looks to me like messing up the language... You might as well just insert the 'singleton', 'observer' and 'factory' keywords.

  • Avner Kashtan said

    Well, yes. Certainly. I'd like programming languages to give me higher levels of abstraction, like LINQ does. Maybe C# isn't the language for it. Then again, I can certainly see it going there.

  • Anastasiosyal said

    I think that a visual tooltip in the editor would be good enough for this scenario (just like resharper does) Adding a key word for recursion would allow for two seperate ways of implementing the same piece of code. If you would expect recursiveness by key word you would be more likely to miss it when it is typed in as a function call. There are also issues with mutual recursion (as already stated above) and recursion via delegates that cant be detected at compile time.

  • Moshe Eshel said

    It's been said here, but why would you want such a thing? Leave something for the developer writing/reading the code to think about... If you're writing the code, you should know what you're doing, and in the worst case detect it during your testing. If you are reading the code, I hope you are paying enough attention to see that is a recursion... In reference to the goal of explicitness, I think this is a bit too much, no need to specify that a function is recursive, it is part of what the function itself does...

  • Avner Kashtan said

    Moshe: Programming is not a game. We don't need to give ourselves artifical handicaps to "keep it interesting" or "because it should be a challenge". Programming is hard. Our goal is to produce the best software with the least bugs. I want our tools and our languages to help us with that, not get in our way. "Leave something for the developer to think about" and "you should be paying attention" are in no way reasons to avoid using tools. By the same token you're discounting intellisense or even meaningful compiler errors - after all, the programmer can always do it himself. I'm taking your argument to extremes, of course, but the point still stands. There are plenty of things for the programmer to think about - design, business logic, and so forth. It's 2007, for chrissakes. We have a whole new set of mistakes to do, why repeat the same ones people have been doing since the 60's?

  • Coworker said

    Anastasiosyal - I don't think there should be two ways of creating recursion. The "old" method should not be compilable. Moshe - you never wrote code which caused a bug, but didn't see it right after compiling and running it for the first time? What if a co-worker encounters it first? Why NOT have the compile time help? And about the "clearity" and the amount of keywords in a language - what make a language dirty is not excessive keywords, it's BAD or confusing keywords. "foreach", "where" or "unsafe" do not bother anyone becuase they are clear and usable. Your arguments basically call for abolishing every keyword which could be otherwise implemented with user code. This is, in my mind, not very progressive.

  • Vikram said

    I am totally against inclusion of such keyword in the language. Why add a totally useless keyword like that. Personally i feel the keyword will have no use whatsoever. It does not add anything to the language.

  • Avner Kashtan said

    Vikram: Could you please add any constructive criticisms, rather than "I think it's bad"? I've given several reasons for - more explicitness about recursion and so forth. I put it up here to hear more opinions, both good and bad. But just saying "no" isn't really helping me understand your reasoning.

  • Chris said

    Sorry to resurrect this, but there *is* one case where this is useful - recursion of an anonymous function. The existing solution (even with C# 3.0) is incredibly messy, involving the Y combinator. I believe Wes Dyer has written about how to do anonymous recursion this way...

  • ipad accessories said

    ----------------------------------------------------------- "You misplaced me, buddy. I necessarily mean, I suppose I get what youre saying. I get where youre returning from. But you just seem to have forgotten that you'll find individuals on the market who can see this challenge for what it truly is and may possibly not concur with you. You seem to alienate a entire bunch of individuals who might happen to be followers of your blog site."

  • ipad app said

    ----------------------------------------------------------- "Hi there, I observe that your printed content is somewhat understanding since it talks about plenty of interesting details. In Any Occasion, was questioning whether you would wish to interchange internet hyperlinks with my web page, as I'm looking to ascertain contacts to further amplify and gain ground for my internet portal. I do not mind you laying my internet links in the primary web page, just approving this links on this specific web web page is extra than adequate. Anyway, would you be kind enough message me back at my website if you might be eager in swapping links, I'd genuinely worth that. Thanks a lot and I hope to hear from you shortly! "

Comments have been disabled for this content.