Live data from Hacker News

What's New in C# 6.0 [video]

channel9.msdn.com

71–80 of 145 posts

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

#71

Earlier quoted context omitted.

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

Still wish they would implement something better for INotifyPropertyChanged like key-value observing in obj-c or object.observe proposed for js. Basically automatic property changed events. At least this removes the magic strings in the boiler plate.

I've really wanted to have some sort of property token similar to how we can use method groups as tokens for event subscriptions and delegate creation.

I've also wanted a system similar to dependency properties in WPF that was a little lighter weight. DPs do pretty much everything i could ask for from change notification to binding to pluggable validation, I just wish they we not so tied into the WPF code so i could apply them to my data layer.

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

#72

Still hoping they add the !(non-nullable) operator. I know its hard http://blog.coverity.com/2013/11/20/c-non-nullable-reference... But dang I would appreciate it. So much code is cluttered with null checks that increases the robustness of the code at the cost of correctness, readability, and poorly defined behavior.

Aren't you just shifting the problem rather than solving it? For example, let's say I am calling a function which returns an object: var myStuff = new GiveMeStuff().GenerateStuff(1337); The return of this value can be valid "stuff," an exception, or null. If we remove null as an option, what happens when internally an exception is thrown within GenerateStuff()? Does it re-throw that exception? Or do we now need a pro…

Null values don't go away, it's just that reference types aren't by default nullable. Your function can still return null (if you really want it to) as long as that is indicated by the return type. What you can't do is directly assign the possibly null return value of your function to a non-nullable reference.

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

#73
post #18

While all of the changes look nice in terms of writing less code, they are the kind of syntactic sugar I learned to hate in CoffeeScript. Mostly because the code was so much denser and harder to read. Especially when reading other people's code. As I write more and more code, the more I want simplicity and ease of understanding over typing a few less characters or having more elegant code.

>>> the more I want simplicity and ease of understanding over typing a few less characters

True, coming from Java where you have to type a lot to get a simple thing done I seem to be gravitating towards languages which have clean, simple syntax that allows you to actually think about the problem. I've been playing with python and scheme, I'll have a go with C# soon, now its been open-sourced.

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

#74
post #62

Earlier quoted context omitted.

Calling IsNullOrWhiteSpace on an instance looks even more counter-intuitive to me, though – it wouldn't work on null if it were a real instance method.

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.IsNullOrWhiteSpace.

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

#75
I think they missed a trick if the goal was to reduce boilerplate; which I'm all for, I'm very much moving away from C# to F# for this reason (and a few others).

Why this:

    public int X { get; }
    public int Y { get; } = 5;
And not this:

    public int X get;
    public int Y get = 5;
The braces serve absolutely no purpose anymore, the semi-colon doesn't serve as a separator between statements. So why leave them?

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

#76
post #18

While all of the changes look nice in terms of writing less code, they are the kind of syntactic sugar I learned to hate in CoffeeScript. Mostly because the code was so much denser and harder to read. Especially when reading other people's code. As I write more and more code, the more I want simplicity and ease of understanding over typing a few less characters or having more elegant code.

>>> the more I want simplicity and ease of understanding over typing a few less characters True, coming from Java where you have to type a lot to get a simple thing done I seem to be gravitating towards languages which have clean, simple syntax that allows you to actually think about the problem. I've been playing with python and scheme, I'll have a go with C# soon, now its been open-sourced.

Go would fit that definition quite nicely as well. It may be worth adding to your list of things to check out.

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

#78
post #75

I think they missed a trick if the goal was to reduce boilerplate; which I'm all for, I'm very much moving away from C# to F# for this reason (and a few others). Why this: public int X { get; } public int Y { get; } = 5; And not this: public int X get; public int Y get = 5; The braces serve absolutely no purpose anymore, the semi-colon doesn't serve as a separator between statements. So why leave them?

Because people like braces (they provide structure) and there is a risk to break backward compatibility. Granted the whole ;} = 5; syntax is not great ....

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

#80
post #75

I think they missed a trick if the goal was to reduce boilerplate; which I'm all for, I'm very much moving away from C# to F# for this reason (and a few others). Why this: public int X { get; } public int Y { get; } = 5; And not this: public int X get; public int Y get = 5; The braces serve absolutely no purpose anymore, the semi-colon doesn't serve as a separator between statements. So why leave them?

Because people like braces (they provide structure) and there is a risk to break backward compatibility. Granted the whole ;} = 5; syntax is not great ....

That must be why they removed the need for braces with 'lambda' methods right?

It just seems so pointless and ugly, no one is going to write them like this (well, seems unlikely anyway):

    public int X 
    {
        get;
    } = 5;
So they're no longer providing a scope/block structure. How would it break backward compatibility? I'm not suggesting they remove the scoping for properties, it's clearly needed for {get;set;}, but as far as I can tell I can't think of any existing property-name suffix keyword in the C# grammar, so it seems it wouldn't be too hard to get it to work.

The only reason I can think of to not do it is to reserve the option of post property-name keywords for future features.

I've been using public readonly fields instead for a number of years now because of the constant boilerplate. I doubt I'll change to use these auto-properties for the same reasons.

Post reply on HN