So, Microsoft just open sourced most of .NET...

[justmy2cents]

Most of my information comes from http://lists.kde.org/?l=kde-bindings&r=1&w=2 along with what I observe going on in ddobrev's github,

you can see from http://lists.kde.org/?l=kde-bindings...6538814267&w=2 for instance that he has intent to finish things up and release sometime in the near future although checking with ddobrev personally will get you better information than I can gather because you're getting them from the source as opposed to someone who has just played with the bindings and watched mailing lists and repos

thanks, not being kde user i was kinda stuck in that circular limbo, at least you gave me all info where/how to start looking. thanks again

[DanLamb]

you seem to be missing parts too. there is a BIG distinction between c# class variable and class property. class variable can only contain value and initializer. while property contains automatic or custom get and set methods and initializer. another even bigger distinction is that variable won't show up in reflection while properties will. and there is shitload of reasons why would you want one or another.

Why would you want a C# class instance variable instead of a class instance property?

I know the difference between a C# class instance variable and a class instance property. C# properties have more features that C# class instance variables, so why is the latter necessary?

don't know if it is just me, but i grew hatred for scala in manner of minutes when i looked at it long ago. maybe it is the fact that i started long ago with pascal and prefer obvious&readable over features, maybe something else.

... You probably should have a more articulate objection to Scala before you post about it.

i for example can't stand naming conventions in java for the love of me.

What bothers you about the naming conventions? camel case?

[DanLamb]

Further there are functional requirement differences as well, with a property you want to regulate things like access and acceptable values whereas a variable does not have any such requirements placed upon it.

I understand the differences between C# class instance variables and C# class instance properties. The latter has more functionality, you can swap out a naive get/set with non-trivial get/set logic. My point is that you don't need both. When do you need a class instance variable where a property is inappropriate? What is the drawback to the Scala solution?

[Luke_Wolf]

I understand the differences between C# class instance variables and C# class instance properties. The latter has more functionality, you can swap out a naive get/set with non-trivial get/set logic. My point is that you don't need both. When do you need a class instance variable where a property is inappropriate? What is the drawback to the Scala solution?

Backing variables, and other private variables that act as implementation details have no purpose being properties, if you can get rid of backing variables as a language necessity then using properties only when dealing with classes would be okay and variables only inside functions, until then I'm personally in favour of leaving it up to the developer to opt in.

I decided to look up the Scala version of properties and found this http://dustinmartin.net/getters-and-setters-in-scala/

Unless you have corrections to make vs that blog, the Scala solution is exactly the same as the C# solution other than defaulting to properties as opposed to making properties optional.

And I don't know about you but I find

private T _backingVariable;
public T Property
{
    get
    {
         return _backingVariable;
    }
    set
    {
         //stuff
    }
}

a lot more readable syntactically than

private var _backingVariable;
def Property = _backingVariable
def Property_ = //stuff;

unless I knew Scala I would look at that code and have no idea whats going on, whereas it's very obvious in C# that a property is a property.

[DanLamb]

Backing variables, and other private variables that act as implementation details have no purpose being properties, if you can get rid of backing variables as a language necessity then using properties only when dealing with classes would be okay and variables only inside functions, until then I'm personally in favour of leaving it up to the developer to opt in.

Why can't you use a backing property in C# instead of using a backing class instance variable in C#? The property may be overkill, but you don't lose anything.

private var _backingVariable;
def Property = _backingVariable
def Property_ = //stuff;

unless I knew Scala I would look at that code and have no idea whats going on, whereas it's very obvious in C# that a property is a property.

I give you credit for actually looking it up. The Scala code is completely readable, you just aren't used to it having obviously never used Scala before.

The Scala code you gave is a property with a custom getter/setter. In the common trivial case, where get/set have no custom logic, it is even simpler and more readable.

For a read/write property (aka variable) that can later be converted to a full geter/setter if need be without breaking binary compatibility or can be overridden in a child class:

var someProp = initialValue

For a read-only property (aka value) that can later be converted to a full geter if need be without breaking binary compatibility or can be overridden in a child class:

val someProp = initialValue

Alternatively, you can declare your class properties in the constructor:

class MyComplex(val real: Double, val imaginary: Double)
val c = new MyComplex(3.0, 4.0)
c.real // 3.0
c.imaginary // 4.0

That is extremely concise, elegant, and very readable. You just aren't used to that.

[droste]

Why can't you use a backing property in C# instead of using a backing class instance variable in C#? The property may be overkill, but you don't lose anything.

Nobody is stopping you from doing this in C#. I use the concept of having both of them as way to describe what is part of the interface of the class (the properties) and what is solely an implementation detail (the class/instance variables). So for me it would be a loss of information to the one who reads my code.

The reason for having different ways to describe "read only" is because there are different ways "read only" is actually enforced.
So for class/instance variables you have the read-only keyword which does exactly what it says. It makes these variables read-only, they are only written one, when they are initialized.
For properties you can have different settings.

For example:

public int A { get; }                 // ---> read-only for everyone
public int A { get; protected set; }  // ---> read-only for everything using this class but not this class and subclasses
public int A { get; private set; }    // ---> read-only for everything using it, but not itself.

So even if it looks like it is a more complicated language it actually helps me making the code less complicated as soon as you understood this.

[DanLamb]

Nobody is stopping you from doing this in C#. I use the concept of having both of them as way to describe what is part of the interface of the class (the properties) and what is solely an implementation detail (the class/instance variables). So for me it would be a loss of information to the one who reads my code.

The reason for having different ways to describe "read only" is because there are different ways "read only" is actually enforced.
So for class/instance variables you have the read-only keyword which does exactly what it says. It makes these variables read-only, they are only written one, when they are initialized.
For properties you can have different settings.

For example:

public int A { get; }                 // ---> read-only for everyone
public int A { get; protected set; }  // ---> read-only for everything using this class but not this class and subclasses
public int A { get; private set; }    // ---> read-only for everything using it, but not itself.

So even if it looks like it is a more complicated language it actually helps me making the code less complicated as soon as you understood this.

The Scala translation of that C# would be the following. I added a dummy wrapping TestClass and an initial value.

class TestClass { val a = 123; } // ---> read-only for everyone
class TestClass { protected var internalA = 123; def a = internalA; } // ---> read-only for everything using this class but not this class and subclasses
class TestClass { private var internalA = 123; def a = internalA; } // ---> read-only for everything using it, but not itself.

I understand the C# system really well. I have worked many years as a full time C# developer and have written/read _mountains_ of C# code.

Scala has an objectively, measurably simpler syntax on this issue. It uses less keywords than C#, it doesn't have the separate syntaxes like C#. Scala uses basically the same syntax for local var/val, instance var/val, and singleton var/val. It supports read-only and read-write and type inference the same way in all three situations. It requires significantly less code in almost every situation. It is a simpler syntax with more concise code that is at least as powerful.

I have never met someone who understood this issue or has used Scala more than a trivial amount and didn't think Scala was a complete 100% improvement over Java and C# on these issues. Most C# developers have never thought about this; they are happy with the tool they use and haven't considered alternatives, and often only read and talk with developers who think the same way.

[Luke_Wolf]

Why can't you use a backing property in C# instead of using a backing class instance variable in C#? The property may be overkill, but you don't lose anything.

I could but I don't see why I would bother doing so, I may not lose anything but I don't really see any useful gain from it either. I mean any checking or whatever I'm going to do is already going to be done in the getter and setter of the public property.

I give you credit for actually looking it up. The Scala code is completely readable, you just aren't used to it having obviously never used Scala before.

that I haven't but I still find structuring and keywords more readable than using underscores

The Scala code you gave is a property with a custom getter/setter. In the common trivial case, where get/set have no custom logic, it is even simpler and more readable.

Well the same goes for C# but property syntax is trivial in both it looks like unless you want to use custom getters and setters

For a read/write property (aka variable) that can later be converted to a full geter/setter if need be without breaking binary compatibility or can be overridden in a child class:

var someProp = initialValue

public T Property {get;set;}
public someClassDefaultConstructor()
{
   Property = initialValue;
}

You do save one line there by having the declaration and definition on the same line

For a read-only property (aka value) that can later be converted to a full geter if need be without breaking binary compatibility or can be overridden in a child class:

val someProp = initialValue

public T Property{get; private set;}

Well conversion is a non-issue because if an individual is using public fields in C# they're an idiot because they're breaking one of the first rules of OOP: Encapsulation, in a language that makes it trivial. In languages where properties are not a language feature it's still heinous but at least it's understandable, however C# is not one of those.

Alternatively, you can declare your class properties in the constructor:

class MyComplex(val real: Double, val imaginary: Double)
val c = new MyComplex(3.0, 4.0)
c.real // 3.0
c.imaginary // 4.0

var c = new {real = 3.0, imaginary = 4.0};
c.real; //3.0
c.imaginary; //4.0

Now those properties are read only since it's an anonymous type but I could have alternatively done this if I wanted them read-write

public class MyComplex 
{    
    public double real{get;set;}
    public double imaginary{get;set;}
}
var c = new MyComplex (){ real = 3.0, imaginary = 4.0};
c.real; //3.0
c.imaginary; //4.0

Which for use cases not more fitting to anonymous types I like having the obvious structured class.

That is extremely concise, elegant, and very readable. You just aren't used to that.

Well at least as regards properties the only neat feature I saw was being able to declare and initialize a property all on the same line, maybe try another language feature example? I am interested in seeing just what's so elegant about Scala but these examples with properties so far aren't particularly convincing.

[Luke_Wolf]

So I decided to look at this

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=csharp&lang2=scala&data=u64q

And it's essentially a wash for these microbenchmarks in terms of code size, for most cases the size of the program is about the same. For some cases scala has a significant advantage but in a similar number of cases C# has a significant advantage (C# saving at most 400 lines vs Scala, where Scala saves 300 lines vs C# in the best cases)...

[Luke_Wolf]

So I decided to look at this

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=csharp&lang2=scala&data=u64q

And it's essentially a wash for these microbenchmarks in terms of code size, for most cases the size of the program is about the same. For some cases scala has a significant advantage but in a similar number of cases C# has a significant advantage (C# saving at most 400 lines vs Scala, where Scala saves 300 lines vs C# in the best cases)...

Whoops looks like that's bytes inside a compressed gzip archive of stripped source code files not lines, which makes it even more of a wash.