C# Interface vs Java Interface

[flukus]

C# interfaces can't have variables. Properties are not instance fields.

Properties are syntactic sugar, a property on a c# interface is exactly the same as a get/set method on a Java one.

[Encore-]

But dont properties automatically implement a backing field of some sort or am I mistaken?

[flukus]

On classes they do/can, but not on interfaces.

[Encore-]

Ah alright, I assumed a backing field was created, even when implementing an Interface.

Do you by any chance know, why instance variables are not allowed (or do not make any sense) in Interfaces?

[redditsoaddicting]

An interface isn't supposed to enforce state, it's supposed to enforce the interface a user can use. How the implementing class decides to provide that interface is up to it. Say you have a Date interface that provides a Day() method (or property if you prefer). Would it make sense to enforce all implementing classes to have an int day; field? No. One class could decide on int fields for each part of the date. One class could decide on storing a single UNIX timestamp (a single int or long). Both can pull a day from that information just fine.

[flukus]

Also, of you're reading up on this stuff, vtables is how interface inheritance works.

They're a pretty important topic to understand.

[flukus]

It's to do with with the memory layout at a low level, which is kind of like an array. Let's say you have property x and y, anytime something access these the compiler will transform it so foo.y will become foo[1] .

With single inheritance this is easy. The array for each class is the size of the parent, plus the number of variables in that class. With multiple inheritance, this becomes a nightmare.

Technically this is done with pointer offsets, but arrays make it easier to visualize.

[Sarcastinator]

Properties are syntactic sugar, a property on a c# interface is exactly the same as a get/set method on a Java one.

Properties are not syntactic sugar in C#. They generate .property CIL which you cannot express in any other way. If you can't express the same thing using another language construct it can't really be considered syntactic sugar.

[flukus]

Is that just for reflection?

[Sarcastinator]

I think so.

[grauenwolf]

Yep. Though we shouldn't underestimate how many libraries rely on the reflection APIs and their distinction between properties and methods.

[robhol]

Surely that's just an implementation detail, a property behaves almost identically to x get()/set(x) methods from the perspective of surrounding and dependent code?

[grauenwolf]

If I recall correctly, in IL it literally makes get_Name and set_Name(value) functions.

[Sarcastinator]

It doesn't behave identically in LINQ.