New C# Syntax  (methods)

This:

string something(string blah)

{

 return blah + "blah!";

}

Becomes:

string something(string blah)

  return blah + "blah!";

Why?

1) It is ALREADY the syntax for branches

2) C# doesn't support default values (thus forcing you to overload like crazy)

3) It would look cleaner

You should be using StringBuilder, strings are immutable

Doesn't C# 4 support default values?

spivonious said:

Doesn't C# 4 support default values?

I hope so.

But if they stripped it from C++ for C# 1.0, I don't see why they would re-add it now.

I agree it would reduce the inconsistency in C#'s block definition, but I'm worried the introduced inconsistency in written code may end up making code look messier.

I've heard a lot of complaints about C-style's acceptance of braceless branches since if you're not reading it carefully you might introduce a bug, thinking a line was being branched when it really was.

Well, at least it isn't as bad as PHP.

W3bbo said:

I agree it would reduce the inconsistency in C#'s block definition, but I'm worried the introduced inconsistency in written code may end up making code look messier.

 

I've heard a lot of complaints about C-style's acceptance of braceless branches since if you're not reading it carefully you might introduce a bug, thinking a line was being branched when it really was.

 

Well, at least it isn't as bad as PHP.

PHP is one giant hack!

I love PHP but I have to admit that it is just a huge hack that programmers HATE and network admin types really love. If you want to do something small or simple then PHP is kick butt, but if you're writing complex projects then stay the heck away.

Plus the way it can mix either code in HTML or HTML in code is just sexy...

ManipUni said:

W3bbo said:

*snip*

PHP is one giant hack!

 

I love PHP but I have to admit that it is just a huge hack that programmers HATE and network admin types really love. If you want to do something small or simple then PHP is kick butt, but if you're writing complex projects then stay the heck away.

 

Plus the way it can mix either code in HTML or HTML in code is just sexy...

@Plus the way it can mix either code in HTML or HTML in code is just sexy...

Don't go mentioning that around serious developers now, especially those fixated with MVC

vesuvius said:

You should be using StringBuilder, strings are immutable

"You should be using StringBuilder, strings are immutable"

?  In case above, SB would not really provide any value.  In this case, sb would only add cycles and another object.

In terms of 1-line methods with no braces.  Personally, I don't see it really creating value.  I very rarely see or write 1 line methods and think it would only add crumbs to the lang.  Feature wise, think there is much richer grass to be had

staceyw said:

vesuvius said:

*snip*

"You should be using StringBuilder, strings are immutable"

 

?  In case above, SB would not really provide any value.  In this case, sb would only add cycles and another object.

 

In terms of 1-line methods with no braces.  Personally, I don't see it really creating value.  I very rarely see or write 1 line methods and think it would only add crumbs to the lang.  Feature wise, think there is much richer grass to be had

 

 

You don't write tons of these?

void something(int y, int z)

 something(0, y, z)

void something (int y, int z)

 something(0, 0, z)

etc

ManipUni said:

staceyw said:

*snip*

You don't write tons of these?

 

void something(int y, int z)

 something(0, y, z)

 

void something (int y, int z)

 something(0, 0, z)

 

etc

.Net 4.0 adds default parameters, so it wouldn't be necessary anymore.

Sven Groot said:

ManipUni said:

*snip*

.Net 4.0 adds default parameters, so it wouldn't be necessary anymore.

Default and named parameters both.

wkempf said:

Sven Groot said:

*snip*

Default and named parameters both.

Yeah, I think that named parameters will do wonders for readability and maintainability of a codebase. I love how the design process of C# is driven by what developers actually need in practice, and not just by what looks nice in theory.

TommyCarlier said:

wkempf said:

*snip*

Yeah, I think that named parameters will do wonders for readability and maintainability of a codebase. I love how the design process of C# is driven by what developers actually need in practice, and not just by what looks nice in theory.

Yeah, I'm not sure which is more exciting, the named parameters or the default parameters (named parameters would be nearly pointless without default parameters, but that doesn't change the question)? Glad we're getting both, though. Now if we can only get nameof() into the language.

wkempf said:

TommyCarlier said:

*snip*

Yeah, I'm not sure which is more exciting, the named parameters or the default parameters (named parameters would be nearly pointless without default parameters, but that doesn't change the question)? Glad we're getting both, though. Now if we can only get nameof() into the language.

Talking about a wish list for C#...

Since destructors in C# are essentially useless if you want to execute some code at the exact time when the object goes out of scope, and using try/finally blocks can get messy, I was thinking of other ways to deal with that.

One way would be to add the virtual method "OnScopeExit" to the "object" class. Then you can override that in your own classes to do whatever you want. This won’t need to break old code because if you never overrode object.OnScopeExit, no functionally is modified.

Of course the big problem here is that classes are ref objects, so them going out of scope might be difficult to pinpoint, especially when you can pass that ref along to something else. But there might be a way to determine from the runtime when the last ref goes out of scope (or not).

Then again, it sounds like a can of worms. Any better ideas?

Another wish list item: Any word of getting edit-and-continue to work around anonymous methods? I use anonymous methods a lot and hate the fact that as soon as there is an anonymous method in sight, edit-and-continue is disabled. I love the fact that I can create an empty stub method, put a breakpoint at its start, run, hit the breakpoint and write/debug the whole method without restarting once. But not so much with anonymous methods...

BitFlipper said:

wkempf said:

*snip*

Talking about a wish list for C#...

 

Since destructors in C# are essentially useless if you want to execute some code at the exact time when the object goes out of scope, and using try/finally blocks can get messy, I was thinking of other ways to deal with that.

 

One way would be to add the virtual method "OnScopeExit" to the "object" class. Then you can override that in your own classes to do whatever you want. This won’t need to break old code because if you never overrode object.OnScopeExit, no functionally is modified.

 

Of course the big problem here is that classes are ref objects, so them going out of scope might be difficult to pinpoint, especially when you can pass that ref along to something else. But there might be a way to determine from the runtime when the last ref goes out of scope (or not).

 

Then again, it sounds like a can of worms. Any better ideas?

 

Another wish list item: Any word of getting edit-and-continue to work around anonymous methods? I use anonymous methods a lot and hate the fact that as soon as there is an anonymous method in sight, edit-and-continue is disabled. I love the fact that I can create an empty stub method, put a breakpoint at its start, run, hit the breakpoint and write/debug the whole method without restarting once. But not so much with anonymous methods...

What you're talking about is reference counting, which has its own problems, as anyone who has used COM will testify.

I don't see what the issue is with a "using' block anyway, I don't understand why it's "messy".

Sven Groot said:

BitFlipper said:

*snip*

What you're talking about is reference counting, which has its own problems, as anyone who has used COM will testify.

 

I don't see what the issue is with a "using' block anyway, I don't understand why it's "messy".

Yea I know ref counting is nasty. And the problem with "using" is that it works fine for a few objects, but when you have a lot it does become "messy". Although you can do this to clean it up a bit:

using (MyClass a = new MyClass())

using (MyClass b = new MyClass())

using (MyClass c = new MyClass())

using (MyClass d = new MyClass())

{

  ...

}

BitFlipper said:

wkempf said:

*snip*

Talking about a wish list for C#...

 

Since destructors in C# are essentially useless if you want to execute some code at the exact time when the object goes out of scope, and using try/finally blocks can get messy, I was thinking of other ways to deal with that.

 

One way would be to add the virtual method "OnScopeExit" to the "object" class. Then you can override that in your own classes to do whatever you want. This won’t need to break old code because if you never overrode object.OnScopeExit, no functionally is modified.

 

Of course the big problem here is that classes are ref objects, so them going out of scope might be difficult to pinpoint, especially when you can pass that ref along to something else. But there might be a way to determine from the runtime when the last ref goes out of scope (or not).

 

Then again, it sounds like a can of worms. Any better ideas?

 

Another wish list item: Any word of getting edit-and-continue to work around anonymous methods? I use anonymous methods a lot and hate the fact that as soon as there is an anonymous method in sight, edit-and-continue is disabled. I love the fact that I can create an empty stub method, put a breakpoint at its start, run, hit the breakpoint and write/debug the whole method without restarting once. But not so much with anonymous methods...

"One way would be to add the virtual method "OnScopeExit" to the "object" class."

Not a gc expert.  But not sure that is workable.  You would still be waiting for the GC to determine when something went out of scope which in my understanding is lazy. So not sure how much time you would actually gain.  Also, would this get called after your object goes out of scope?  If so, your inside an object that is now out of scope so there is no "this".  If it is called before collection, are we pausing collection again until your method exits?  What if you have an async callback that never gets called or not called for long time? Seems like it could be messy.

BitFlipper said:

Sven Groot said:

*snip*

Yea I know ref counting is nasty. And the problem with "using" is that it works fine for a few objects, but when you have a lot it does become "messy". Although you can do this to clean it up a bit:

 

using (MyClass a = new MyClass())

using (MyClass b = new MyClass())

using (MyClass c = new MyClass())

using (MyClass d = new MyClass())

{

  ...

}

 

If the type of variable inside of using statement is the same for multiple stytements you can join statements in this way:

using (MyClass a = expression1, b = expression2, c = expression3 ...)

     statement;

On OnScopeExit - If this existed then runtime would have to check whether object is reachable almost at every reference variable assignment. While we would gain deterministic deallocation (which might be great for real-time applications) it would be also a lot less performat.

I wonder though if any language has done it, or is it completely infeasible? It would probably involve mad optimization tricks, it's certainly not for languages that want to be fast, but memory-safe language without GC is an interesting concept .