Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's New in C# 6.0 [video]

channel9.msdn.com

Post reply on HN
Print view View original

91–100 of 145 posts

Re: What's New in C# 6.0 [video]

#91

Post by seanmcdirmid »

Tloewald wrote: post #20

Nothing not to love -- a whole bunch of syntax sugar that makes code cleaner without messing around with core concepts that breaks code conceptually. It's also great to see how quickly good ideas permeate the language landscape today versus ten years ago (or maybe it's just good ideas finally permeating the landscape all at once).

From what I understand, this has been on the list for awhile, they are just working through it in each version. None of the ideas are very new at all, and could have been on the list quite awhile ago.

Re: What's New in C# 6.0 [video]

#93

Post by seanmcdirmid »

jsmeaton wrote: post #83
algorithmsRcool wrote: post #12

Earlier quoted context omitted.

And also for INotifyPropertyChanged! (Although CallerMemberName helped that some in C#5.)

I really really want property change notifications on auto-properties. Having to compare the incoming value against an explicit backing field is the cause of most of my boilerplate code when using WPF.

I wrote a framework that wrapped dependency properties to accomplish things like this once:

http://bling.codeplex.com

But my feeling is that it was kind of hopeless to do in C#: it is just so different from the language semantics. Something like FRP (real FRP, not Rx) or managed time [1] works much better, IMHO, but requires drastic language changes.

JavaFX Script (F3) also included data binding straight into the language, and is probably an idea of how to do it for C#.

[1] http://research.microsoft.com/en-us/people/smcdirm/managedti...

Re: What's New in C# 6.0 [video]

#94

Post by seanmcdirmid »

zer0nes wrote: post #86
cesarbs wrote: post #22

I love the new read-only auto properties. 90% of the objects I write are immutable and it's a pain to declare all those private readonly backing fields just to return them in getters.

Why don't you use public readonly fields?

Interfaces and overriding usually.

Re: What's New in C# 6.0 [video]

#95

Post by seanmcdirmid »

_random_ wrote: post #41
moron4hire wrote: post #15

Using static classes as namespaces addresses something I was just complaining about a week ago. Let's take it a step further! Just let us put bare functions in namespaces without the dance of the static class.

F# module == C# static class. What is the problem?

static classes and namespaces seem to have a lot of overlap now. Static partial classes can almost completely replace namespaces now.

Re: What's New in C# 6.0 [video]

#96

Post by Arnavion »

louthy wrote: post #87
zer0nes wrote: post #84

Earlier quoted context omitted.

public int X { get; } is more consistent with how properties are declared. Consistency is important. If you care about clean code, here's an even better way public readonly int X; They are not exactly the same but they are equivalent in most cases. In exotic cases where you're required to use auto-getters, adding the brackets wouldn't hurt.

> public int X { get; } is more consistent with how properties are declared. Consistency is important. As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax? It's inconsistent and therefore unacceptable right? If everything has to be consistent we wouldn't have LINQ, lambdas, generics, etc. The braces are for scope in C# and all C derivative languages. There i…

>As mentioned in my other reply. If that were the case, why have they just changed the method declaration syntax?

They did change the property declaration syntax too.

    public int X => 5;
is the same as

    public int X { get { return 5; } }
This is exactly the same change they made to the method declaration syntax, so I'm not sure what you're complaining about.

Of course it isn't identical to public int X { get; } because the latter is assignable in the constructor. But comparing _that_ to methods is apples to oranges since methods aren't assignable.

Re: What's New in C# 6.0 [video]

#97

Post by Arnavion »

ptx wrote: post #74
Someone1234 wrote: post #65

Earlier quoted context omitted.

It is consistent with how other .Net libraries work (particularly the string ones). It also works fine on null as long as the type of null is string.

It works because it's an extension method, but aren't extension methods supposed to make things nice and consistent by making it look as if you're calling an instance method? Since this would be completely broken if it were an instance method, the reader might be surprised at first until they realize it's an extension method. So all I'm saying is that it's no less "counter-intuitive" than the normal string.IsNullOrWh…

Indeed, the fact that extension methods happen to work with `this == null` is more of a bonus feature than something that should be deliberately used.

Re: What's New in C# 6.0 [video]

#99

Post by rzimmerman »

Tloewald wrote: post #20

Nothing not to love -- a whole bunch of syntax sugar that makes code cleaner without messing around with core concepts that breaks code conceptually. It's also great to see how quickly good ideas permeate the language landscape today versus ten years ago (or maybe it's just good ideas finally permeating the landscape all at once).

It is really nice to see good ideas percolate in from other places. I like the focus on making syntax cleaner and less boilerplate without being overly terse.

Re: What's New in C# 6.0 [video]

#100

Post by noblethrasher »

hkon wrote: post #81
noblethrasher wrote: post #27

I'm a tiny bit disappointed with the inclusion of exception filters, but I suppose it is pragmatic feature. I'm fond of a pattern where error codes can be implicitly converted to Exceptions[1]. It's often argued that exceptions are for things that your program cannot handle and error codes are for things that it can. But, in my experience, whether or not a bad condition is an error or an exception depends upon the la…

I've never seen the arguments for error codes vs exception. Care to explain briefly or link me some information?

Here's the first essay I remember on the subject: http://www.joelonsoftware.com/items/2003/10/13.html
Post reply on HN