<p>In an object oriented language with single inheritance, there is often the concept &quot;interface&quot;, separate from classes, as a replacement of what would otherwise require multiple inheritance. It started out as only supporting abstract member functions (methods). But supports for a concrete default implementation, and non-virtual member functions are added back in some languages, such as <a href="https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/default-interface-methods#modifiers-in-interfaces" rel="nofollow noreferrer">C#</a>. The only thing absolutely not supported in interfaces is member variables. But does it have a reason, other than it's rarely used and no language designers have thought of it yet?</p>
<p>Some languages support properties, which are effectively pairs of get/set member functions, that could do everything a member variable could do, which might be an explanation of the lack of motivation of supporting the later. But property has its own problems, such as the semantics when assignment is a redefinable operator (which doesn't apply to C#).</p>
<p>It's easy to think of how it would get implemented. If the interface has a standalone vtable pointer, allocate memory after it. If it is not the case, calculate the offset like how vtable offsets are calculated. In the worst case, it could save the offset in the vtable, like a &quot;virtual member variable&quot;.</p>
<p>Actually in the worst case, one could just use multiple inheritance. But by asking whether it is meaningful, I mean if a language supports this without much more considerations, could it still keep every advantage of single inheritance?</p>

<object-oriented><interfaces>
Is it meaningful to disallow member variables in interfaces?
CC BY-SA 4.0
2024-01-23T11:22:46.817Z
I think interfaces were mostly implemented to allow outside code to interact with a class in a more uniform way, so multiple classes could share the same set of functions even if they are not related to each other. In general it's a good practice to not give direct access to member variables to outside code, so the class's code can change, and as long as the functions remain the same, all outside code that interacts with it will still work. My guess is that's why they haven't added member variables to interfaces, I don't think it's a technical limitation or that nobody thought of it.
Tom Tsagkatos
CC BY-SA 4.0
2024-01-23T13:54:57.800Z
Kotlin allows properties in its interfaces, which are essentially sugar for `getX()` and `setX()`, but you could also treat them as member variables.
Seggan
CC BY-SA 4.0
2024-01-24T06:23:12.080Z
Nim's interfaces equivalent ("concepts") describe both member variables and member functions, because in a language with uniform function call syntax, there is no syntactic distinction. https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax#Nim_programming_language, https://nim-lang.org/docs/manual_experimental.html#concepts
apropos
CC BY-SA 4.0
2024-01-24T14:35:15.673Z
Some general questions about multiple inheritance on se.se:

[Is there any "real" reason multiple inheritance is hated?](https://softwareengineering.stackexchange.com/q/218458/181279)

[Multiple inheritance use cases](https://softwareengineering.stackexchange.com/q/100993/181279)

[How are mixins or traits better than plain multiple inheritance?](https://softwareengineering.stackexchange.com/q/250776/181279)

[Why do you reduce multiple inheritance to the diamond problem?](https://softwareengineering.stackexchange.com/q/303088/181279)

I'm not going to repeat them here.
user23013
CC BY-SA 4.0
2024-01-24T14:38:19.343Z
Also related: [What are the different class-like constructs that languages use today?](https://langdev.stackexchange.com/q/2116/1149)
user23013
<p>Tyr actually has this for several years now. An example can be found <a href="https://github.com/tyr-lang/test.conformance/blob/master/0.5.0/accept/interfaceFieldOverride/mar.tyr" rel="nofollow noreferrer">here</a>.</p>
<p>In contrast to what the other answers say, there is a straight-forward extension of common interface implementations for languages with single-inheritance classes. I assume that for functions from interfaces, there is an ITable in each class repr akin to <a href="https://softwareengineering.stackexchange.com/questions/373806/implementation-of-pure-abstract-classes-and-interfaces/373810#373810">this post</a>.</p>
<p>Now, the extension to fields is essentially storing the offset from the <em>object</em> start to the field start. Also, each interface field requires an ITable key in the same way as interface functions get one.</p>
<p>This has two consequences. One is that ITables no longer have a type in most languages and get larger if we assume this feature to be used excessively. However, they are smaller if compared against getter setter pairs. The other consequence is that ifield access shares the extra cost of essentially static call versus icall. The reason is that the difference against the object base pointer is no longer statically known and has to be computed by loading the class, loading the itable, searching the itable and then using the result as delta. That excess cost is, however, only to be paid for an access over interface views.</p>
<p>I'm confident that Tyr-style ifield access can be added to, both, Java and C# without breaking something else. Nonetheless, I would equally expect that there is some development effort as this is something at the very core of the implementation.</p>

CC BY-SA 4.0
2024-01-23T17:42:51.750Z
2024-01-23T17:42:51.750Z
feldentm
CC BY-SA 4.0
2024-01-23T17:45:08.237Z
*"Now, the extension to fields is essentially storing the offset from the object start to the field start."* ─ Absolutely. So then why have you commented on my answer to say that it has nothing to do with static vs. dynamic binding? If you have to look up the offset of the field in a table based on the object's runtime type, then you're doing dynamic binding!
kaya3
CC BY-SA 4.0
2024-01-23T18:36:59.400Z
@kaya3 I referred to that post only because you used Java as an example. If you call that dynamic binding then Java is using dynamic binding according to that post. But there are arguably easier solutions if you use bloated objects or fat pointers.
user23013
<p>The reason that languages like Java (which C# is based on) don't allow member variables in interfaces, is because member variable accesses are statically bound. That is, in code like <code>obj.foo</code>, the name <code>foo</code> is resolved to a field of a particular class at compile-time, based on the static type of <code>obj</code>. Consider these classes:</p>
<pre class="lang-java prettyprint-override"><code>class A {
    String foo = &quot;A.foo&quot;;
    String bar() { return &quot;A.bar&quot;; }
}
class B extends A {
    String foo = &quot;B.foo&quot;;
    String bar() { return &quot;B.bar&quot;; }
}
</code></pre>
<p>Now if you declare <code>A obj = new B();</code>, <code>obj.foo</code> will have the value <code>&quot;A.foo&quot;</code> even though <code>obj.bar()</code> returns <code>&quot;B.bar&quot;</code>. This is because in Java, methods are dynamically bound and can be overridden, but fields are statically bound and cannot be overridden.</p>
<p>So then suppose you could have an interface like this (and suppose <code>A</code> implements it):</p>
<pre class="lang-java prettyprint-override"><code>interface C {
    String foo;
}
</code></pre>
<p>The declaration <code>C c = new A();</code> then allows us to write a member variable access <code>c.foo</code> on an object whose static type is <code>C</code>. So then what should the value of <code>c.foo</code> be? If we statically resolve the name <code>foo</code> to the field declared in the interface <code>C</code>, then we find the interface declares no value for this field.</p>
<hr />
<p>All of that said, interfaces with member variables make perfect sense in languages where member variable accesses <em>are</em> dynamically bound. TypeScript is such a language:</p>
<pre class="lang-typescript prettyprint-override"><code>class A {
    foo: string = 'A.foo';
    bar(): string { return 'A.bar'; }
}
class B extends A {
    foo: string = 'B.foo';
    bar(): string { return 'B.bar'; }
}
</code></pre>
<p>Now if we declare <code>let obj: A = new B();</code>, both accesses <code>obj.foo</code> and <code>obj.bar()</code> have the values <code>'B.foo'</code> and <code>'B.bar'</code> respectively, since they are both dynamically bound.</p>

CC BY-SA 4.0
2024-01-23T16:04:24.113Z
2024-01-23T16:04:24.113Z
kaya3
CC BY-SA 4.0
2024-01-23T17:02:04.873Z
If [this post](https://softwareengineering.stackexchange.com/a/373810/181279) is to be trusted, it always need dynamically looking for the vtable of C in A, even if the static type is C. Looking for the position of C.foo isn't more complicated.
user23013
CC BY-SA 4.0
2024-01-23T17:05:38.003Z
@user23013 You can say it "isn't more complicated", but the fact is that Java doesn't have dynamically bound member variable accesses; vtables don't include field offsets because fields aren't accessed through vtables. JVM bytecode likewise has no instruction for accessing dynamically bound fields, because there are no dynamically bound fields.
kaya3
CC BY-SA 4.0
2024-01-23T17:13:52.477Z
Yes I understand that Java historically didn't include this feature in its design. And I understand it requires more work, for a feature that isn't too useful. But I want to know whether there are other fundamental reasons.
user23013
CC BY-SA 4.0
2024-01-23T17:16:56.993Z
@user23013 If by "fundamental reasons" you mean reasons why this couldn't be done (or isn't done) in any language, I think the fact that it *is* done in some languages (e.g. TypeScript) should definitively answer that.
kaya3
CC BY-SA 4.0
2024-01-23T17:24:44.580Z
Maybe I should ask a question about the advantages of single inheritance over multiple inheritance first. For fundamental reasons I mean it breaks any of them.
user23013
CC BY-SA 4.0
2024-01-23T17:26:09.487Z
The answer isn't correct. There is no interaction with static vs. dynamic binding as the kind of the defining type for a field is static knowledge.
feldentm
CC BY-SA 4.0
2024-01-23T17:38:24.597Z
@feldentm Yes, e.g. you can statically determine that the field `foo` belongs to the interface `C` in the example I gave. That doesn't help when it comes to accessing the field, because `C` doesn't declare a value for the field. If you wanted it to instead resolve it to a field declared by a class which implements `C`, you would have to check the object's class at runtime, i.e. do dynamic binding.
kaya3
CC BY-SA 4.0
2024-01-23T17:46:24.520Z
@kaya3 bind what exactly at runtime? I don't think that we talk about the same bound entity here.
feldentm
CC BY-SA 4.0
2024-01-23T17:55:00.687Z
@feldentm The binding of the name (in this case `foo`) to the implementation of a member of that name (in this case either `A.foo` or `B.foo`). It makes no sense to statically bind the name `foo` to `C.foo`, because `C` provides no implementation of `foo` ─ interface members are abstract. If you want `c.foo` to have the value `"A.foo"` or `"B.foo"` depending on the object's runtime type, then you *must* look up the field using the object's runtime type.
kaya3
CC BY-SA 4.0
2024-01-23T18:35:50.277Z
@kaya3 The name is statically bound to that field. That's what the IMemberKey is. Name, Type and Repr are all statically bound. The only reason why the interface exists at runtime at all is for the sake of dynamic type checking which is OT here.
feldentm
CC BY-SA 4.0
2024-01-23T19:42:36.263Z
@feldentm Honestly I can make no sense of your position here. The fact that something has a static type doesn't mean it is statically bound. If you're looking up the field offset at runtime, based on the object's type at runtime, then you are doing dynamic binding. You might as well argue that `c.bar()` calling an interface method is also statically bound; it isn't.
kaya3
CC BY-SA 4.0
2024-01-23T20:32:52.703Z
In Java and C# it is, in TypeScript it isnt. Only the dispatch part is dynamic. The bindings are static in the former two. I guess if you come from a scripting language, you should have a look at what really happens at runtime because that's fundamentally different. There, it is common to confuse overriding with shadowing; it could be that this is somehow creating confusion here. But those are fundamentally different things.
feldentm
CC BY-SA 4.0
2024-01-23T21:43:57.613Z
@feldentm You seem to define static binding as *any* information about a name being known at compile-time. That is not what static binding means. Yes, the name `bar` in the expression `c.bar()` can be *resolved* at compile-time to the declaration `bar` in the interface `C`; but it cannot be *bound* to an implementation of that method until runtime, when the object's class is known. For you to claim that method calls in Java are statically bound, shows that you are not using the term in the same way as other people.
kaya3
CC BY-SA 4.0
2024-01-23T21:47:29.623Z
On the other hand, if you must insist that (non-static, non-final) methods in Java are statically bound, then you might want to go edit Wikipedia's page about [name binding](https://en.wikipedia.org/wiki/Name_binding), which mentions Java's dynamic dispatch of methods as an example of dynamic binding.
kaya3
CC BY-SA 4.0
2024-01-24T03:25:45.143Z
I *think* the confusion here is about what precisely is being bound statically. That is, it's between statically determining that a method call is to a particular interface method, and statically determining the function address (so to speak) that will execute at run time. The former sort of static binding of interface members *is* present in Java (e.g. overloading), and more visibly in C# where the same method signature can come from multiple interfaces and be implemented independently. This term is slightly overloaded in that way. On the other hand, fields don't need to use the same layers.
Michael Homer
<blockquote>
<p>It's easy to think of how it would get implemented. If the interface has a standalone vtable pointer, allocate memory after it. If it is not, calculate the offset like how vtable offsets are calculated. In the worst case, it could save the offset in the vtable, like a &quot;virtual member variable&quot;.</p>
</blockquote>
<p>You really don't need that interfaces have vtables, or allocates in any way.</p>
<p>An interface that defines a property requires that any implementing class to have that said storage, the same way a method defined in an interface requires that all implementing classes have a method with the same name and same signature.</p>
<blockquote>
<p>Actually in the worst case, one could just use multiple inheritance. But by asking whether it is meaningful, I mean if a language supports this without much more considerations, could it still keep every advantage of single inheritance?</p>
</blockquote>
<p>Yes. The compiler will only check if the implementing class defines the respective property/storage.</p>
<p>Note that is somewhat a niche feature, as a public mutating property is frowned upon most of the time. You may, then, emulate the annotations that are possible in get/set member functions. Something like:</p>
<pre class="lang-dart prettyprint-override"><code>interface InterfaceName {
    var PropertyName: Type { modifier; modifier; }
}
</code></pre>
<p>Where modifier can be one of:</p>
<ul>
<li>Empty: non-mutating, init only;</li>
<li><code>get</code>: can only read from this property</li>
<li><code>set</code>: can only write to this property</li>
<li><code>get; set;</code>: public mutating property</li>
<li><code>raw</code>: direct access, no getter/setter</li>
</ul>
<hr />
<p>As you cited multiple inheritance, I also argue that this can cause collisions, so the language may specify a way to separate each implementation in a possibly separated block/scope, somewhat Rust's traits.</p>

CC BY-SA 4.0
2024-01-23T14:35:02.510Z
2024-01-23T17:17:55.593Z
2024-01-23T17:17:55.593Z
André L F S Bacci
<p>So, theoretically it's possible, and you could argue that some languages (such as Scala via <a href="https://docs.scala-lang.org/tour/traits.html" rel="noreferrer">traits</a>) already support them. But there are a lot of drawbacks and special cases to consider.</p>
<hr />
<p>The problem with member variables (AKA fields), unlike property getters/setters and methods, is that <strong>they change the data layout of the implementer</strong>.</p>
<p>This means you can no longer implement interfaces on primitive types (because a 32-bit integer with a field is no longer 32 bits) or foreign types (because you'd have to change all the foreign code to allocate those types with a different size).</p>
<p>Although some languages (such as Java) already restrict you to implementing interfaces on user-defined types. With that restriction, you could theoretically allow interfaces to contain fields. The problem now is that those are no longer technically &quot;interfaces&quot;, they are abstract classes. <strong>Interfaces, by definition, don't place any restriction on how any of their members are implemented. Requiring a property member to be stored in a field is placing a restriction on that member.</strong></p>
<p>However, interfaces in most languages (e.g. Java) can have default implementations, and they are still technically interfaces because the defaults can be overridden. Similarly, <strong>you can define an interface which contains a field, but it can be overridden to be a virtual property, and that is still technically an interface</strong>. In fact, such an interface can now be implemented on primitives and foreign types, as long as you require implementers to override the field's default and make it into a property.</p>
<p>It's just that in practice, most languages (like <a href="https://kotlinlang.org/docs/interfaces.html#interfaces-inheritance" rel="noreferrer">Kotlin</a>) will require you to explicitly make the interface's property into a field in subclasses. Maybe the language deciders concluded that added clarity isn't worth the lost brevity, or maybe it's a rarely-expected feature.</p>
<pre class="lang-kotlin prettyprint-override"><code>interface RefCounted {
    var refCount: Int
}

class File(path: String) : RefCounted {
    // With your idea we could remove this line...
    override var refCount: Int = 0
}

class Connection(url: String) : RefCounted {
    // ...and remove this line
    override var refCount: Int = 0
}
</code></pre>
<p>Also, a &quot;default&quot; field in an interface must have default initial value, in order to be any different than a property.</p>
<hr />
<p>With regard to vtables, you'd have to store the field's getter and setter in an instance's vtable. You can't just store a field offset because the interface (in order to still technically be an interface) must allow subtypes to override the field into a virtual property. If your language allows abstract classes and multiple inheritance, and the class has a <code>final</code> field (can't be overridden to be virtual), you'd store the offset into the vtable; if it allows abstract classes but not multiple inheritance, you'd give the field a static offset.</p>
<p>To summarize, you can theoretically allow interfaces to contain fields, but:</p>
<ul>
<li>Implementors must be able to &quot;delete&quot; the field by overriding the field with a virtual property.</li>
<li>Any non-user-defined types <em>must</em> override the field into a virtual property.</li>
<li>Functions and data-structures which use the interface can't assume that implementers contain the field and it's not a virtual property.</li>
<li>The field must have a default initial value.</li>
</ul>
<p>This kind of &quot;interface field&quot; is a property (with getter/setter) where the default implementation is via a backing variable.</p>

CC BY-SA 4.0
2024-01-23T13:50:24.810Z
2024-01-23T14:06:15.677Z
2024-01-23T14:06:15.677Z
tarzh
CC BY-SA 4.0
2024-01-23T15:38:51.237Z
By "*..., and non-virtual member functions are added back in some languages*", I expect non-virtual fields in interfaces, at least as an option. And, is it common to allow adding interfaces to preexisted system and library-defined classes? How to look for the appropriate implementation if a virtual function is overridden by a subclass, in such languages?
user23013
CC BY-SA 4.0
2024-01-23T19:41:52.407Z
In languages like Rust and Haskell which allow you to add interfaces to preexisting classes it happens fairly often. But only for user-defined interfaces (either the interface or the type must be user-defined or you can have multiple conflicting ("[incoherent](https://github.com/Ixrec/rust-orphan-rules)") implementations). It's a big benefit IMO, and a sort of enhanced form of extension methods. e.g. a usecase would be to create an interface IsJson, and implement it on Float and String; you don't want to have IsJson in your standard library, but do want to use primitives directly as JSON.
tarzh
# Is it meaningful to disallow member variables in interfaces?
Posted by: username_0 on 2024-01-23
In an object oriented language with single inheritance, there is often the concept "interface", separate from classes, as a replacement of what would otherwise require multiple inheritance. It started out as only supporting abstract member functions (methods). But supports for a concrete default implementation, and non-virtual member functions are added back in some languages, such as [C#](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/default-interface-methods#modifiers-in-interfaces). The only thing absolutely not supported in interfaces is member variables. But does it have a reason, other than it's rarely used and no language designers have thought of it yet?

Some languages support properties, which are effectively pairs of get/set member functions, that could do everything a member variable could do, which might be an explanation of the lack of motivation of supporting the later. But property has its own problems, such as the semantics when assignment is a redefinable operator (which doesn't apply to C#).

It's easy to think of how it would get implemented. If the interface has a standalone vtable pointer, allocate memory after it. If it is not the case, calculate the offset like how vtable offsets are calculated. In the worst case, it could save the offset in the vtable, like a "virtual member variable".

Actually in the worst case, one could just use multiple inheritance. But by asking whether it is meaningful, I mean if a language supports this without much more considerations, could it still keep every advantage of single inheritance?
**Tags:** object-oriented interfaces
> **Comments:**
> **username_1**: I think interfaces were mostly implemented to allow outside code to interact with a class in a more uniform way, so multiple classes could share the same set of functions even if they are not related to each other. In general it's a good practice to not give direct access to member variables to outside code, so the class's code can change, and as long as the functions remain the same, all outside code that interacts with it will still work. My guess is that's why they haven't added member variables to interfaces, I don't think it's a technical limitation or that nobody thought of it.  
> **username_2**: Kotlin allows properties in its interfaces, which are essentially sugar for `getX()` and `setX()`, but you could also treat them as member variables.  
> **username_3**: Nim's interfaces equivalent ("concepts") describe both member variables and member functions, because in a language with uniform function call syntax, there is no syntactic distinction. https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax#Nim_programming_language, https://nim-lang.org/docs/manual_experimental.html#concepts  
> **username_0**: Some general questions about multiple inheritance on se.se:

[Is there any "real" reason multiple inheritance is hated?](https://softwareengineering.stackexchange.com/q/218458/181279)

[Multiple inheritance use cases](https://softwareengineering.stackexchange.com/q/100993/181279)

[How are mixins or traits better than plain multiple inheritance?](https://softwareengineering.stackexchange.com/q/250776/181279)

[Why do you reduce multiple inheritance to the diamond problem?](https://softwareengineering.stackexchange.com/q/303088/181279)

I'm not going to repeat them here.  
> **username_0**: Also related: [What are the different class-like constructs that languages use today?](https://langdev.stackexchange.com/q/2116/1149)  
---
## 4 answers
### Answer by username_8 on 2024-01-23. Score: 5
So, theoretically it's possible, and you could argue that some languages (such as Scala via traits) already support them. But there are a lot of drawbacks and special cases to consider.

The problem with member variables (AKA fields), unlike property getters/setters and methods, is that they change the data layout of the implementer.
This means you can no longer implement interfaces on primitive types (because a 32-bit integer with a field is no longer 32 bits) or foreign types (because you'd have to change all the foreign code to allocate those types with a different size).
Although some languages (such as Java) already restrict you to implementing interfaces on user-defined types. With that restriction, you could theoretically allow interfaces to contain fields. The problem now is that those are no longer technically "interfaces", they are abstract classes. Interfaces, by definition, don't place any restriction on how any of their members are implemented. Requiring a property member to be stored in a field is placing a restriction on that member.
However, interfaces in most languages (e.g. Java) can have default implementations, and they are still technically interfaces because the defaults can be overridden. Similarly, you can define an interface which contains a field, but it can be overridden to be a virtual property, and that is still technically an interface. In fact, such an interface can now be implemented on primitives and foreign types, as long as you require implementers to override the field's default and make it into a property.
It's just that in practice, most languages (like Kotlin) will require you to explicitly make the interface's property into a field in subclasses. Maybe the language deciders concluded that added clarity isn't worth the lost brevity, or maybe it's a rarely-expected feature.
interface RefCounted {
    var refCount: Int
}

class File(path: String) : RefCounted {
    // With your idea we could remove this line...
    override var refCount: Int = 0
}

class Connection(url: String) : RefCounted {
    // ...and remove this line
    override var refCount: Int = 0
}

Also, a "default" field in an interface must have default initial value, in order to be any different than a property.

With regard to vtables, you'd have to store the field's getter and setter in an instance's vtable. You can't just store a field offset because the interface (in order to still technically be an interface) must allow subtypes to override the field into a virtual property. If your language allows abstract classes and multiple inheritance, and the class has a final field (can't be overridden to be virtual), you'd store the offset into the vtable; if it allows abstract classes but not multiple inheritance, you'd give the field a static offset.
To summarize, you can theoretically allow interfaces to contain fields, but:

Implementors must be able to "delete" the field by overriding the field with a virtual property.
Any non-user-defined types must override the field into a virtual property.
Functions and data-structures which use the interface can't assume that implementers contain the field and it's not a virtual property.
The field must have a default initial value.

This kind of "interface field" is a property (with getter/setter) where the default implementation is via a backing variable.
> **Comments:**
> **username_0** (2024-01-23): By "*..., and non-virtual member functions are added back in some languages*", I expect non-virtual fields in interfaces, at least as an option. And, is it common to allow adding interfaces to preexisted system and library-defined classes? How to look for the appropriate implementation if a virtual function is overridden by a subclass, in such languages?  
> **username_8** (2024-01-23): In languages like Rust and Haskell which allow you to add interfaces to preexisting classes it happens fairly often. But only for user-defined interfaces (either the interface or the type must be user-defined or you can have multiple conflicting ("[incoherent](https://github.com/Ixrec/rust-orphan-rules)") implementations). It's a big benefit IMO, and a sort of enhanced form of extension methods. e.g. a usecase would be to create an interface IsJson, and implement it on Float and String; you don't want to have IsJson in your standard library, but do want to use primitives directly as JSON.  
---
### Answer by username_4 on 2024-01-23. Score: 1
Tyr actually has this for several years now. An example can be found [here](https://github.com/tyr-lang/test.conformance/blob/master/0.5.0/accept/interfaceFieldOverride/mar.tyr).

In contrast to what the other answers say, there is a straight-forward extension of common interface implementations for languages with single-inheritance classes. I assume that for functions from interfaces, there is an ITable in each class repr akin to [this post](https://softwareengineering.stackexchange.com/questions/373806/implementation-of-pure-abstract-classes-and-interfaces/373810#373810).

Now, the extension to fields is essentially storing the offset from the *object* start to the field start. Also, each interface field requires an ITable key in the same way as interface functions get one.

This has two consequences. One is that ITables no longer have a type in most languages and get larger if we assume this feature to be used excessively. However, they are smaller if compared against getter setter pairs. The other consequence is that ifield access shares the extra cost of essentially static call versus icall. The reason is that the difference against the object base pointer is no longer statically known and has to be computed by loading the class, loading the itable, searching the itable and then using the result as delta. That excess cost is, however, only to be paid for an access over interface views.

I'm confident that Tyr-style ifield access can be added to, both, Java and C# without breaking something else. Nonetheless, I would equally expect that there is some development effort as this is something at the very core of the implementation.
> **Comments:**
> **username_5** (2024-01-23): *"Now, the extension to fields is essentially storing the offset from the object start to the field start."* ─ Absolutely. So then why have you commented on my answer to say that it has nothing to do with static vs. dynamic binding? If you have to look up the offset of the field in a table based on the object's runtime type, then you're doing dynamic binding!  
> **username_0** (2024-01-23): @kaya3 I referred to that post only because you used Java as an example. If you call that dynamic binding then Java is using dynamic binding according to that post. But there are arguably easier solutions if you use bloated objects or fat pointers.  
---
### Answer by username_5 on 2024-01-23. Score: 0
The reason that languages like Java (which C# is based on) don't allow member variables in interfaces, is because member variable accesses are statically bound. That is, in code like obj.foo, the name foo is resolved to a field of a particular class at compile-time, based on the static type of obj. Consider these classes:
class A {
    String foo = "A.foo";
    String bar() { return "A.bar"; }
}
class B extends A {
    String foo = "B.foo";
    String bar() { return "B.bar"; }
}

Now if you declare A obj = new B();, obj.foo will have the value "A.foo" even though obj.bar() returns "B.bar". This is because in Java, methods are dynamically bound and can be overridden, but fields are statically bound and cannot be overridden.
So then suppose you could have an interface like this (and suppose A implements it):
interface C {
    String foo;
}

The declaration C c = new A(); then allows us to write a member variable access c.foo on an object whose static type is C. So then what should the value of c.foo be? If we statically resolve the name foo to the field declared in the interface C, then we find the interface declares no value for this field.

All of that said, interfaces with member variables make perfect sense in languages where member variable accesses are dynamically bound. TypeScript is such a language:
class A {
    foo: string = 'A.foo';
    bar(): string { return 'A.bar'; }
}
class B extends A {
    foo: string = 'B.foo';
    bar(): string { return 'B.bar'; }
}

Now if we declare let obj: A = new B();, both accesses obj.foo and obj.bar() have the values 'B.foo' and 'B.bar' respectively, since they are both dynamically bound.
> **Comments:**
> **username_0** (2024-01-23): If [this post](https://softwareengineering.stackexchange.com/a/373810/181279) is to be trusted, it always need dynamically looking for the vtable of C in A, even if the static type is C. Looking for the position of C.foo isn't more complicated.  
> **username_5** (2024-01-23): @user23013 You can say it "isn't more complicated", but the fact is that Java doesn't have dynamically bound member variable accesses; vtables don't include field offsets because fields aren't accessed through vtables. JVM bytecode likewise has no instruction for accessing dynamically bound fields, because there are no dynamically bound fields.  
> **username_0** (2024-01-23): Yes I understand that Java historically didn't include this feature in its design. And I understand it requires more work, for a feature that isn't too useful. But I want to know whether there are other fundamental reasons.  
> **username_5** (2024-01-23): @user23013 If by "fundamental reasons" you mean reasons why this couldn't be done (or isn't done) in any language, I think the fact that it *is* done in some languages (e.g. TypeScript) should definitively answer that.  
> **username_0** (2024-01-23): Maybe I should ask a question about the advantages of single inheritance over multiple inheritance first. For fundamental reasons I mean it breaks any of them.  
> **username_4** (2024-01-23): The answer isn't correct. There is no interaction with static vs. dynamic binding as the kind of the defining type for a field is static knowledge.  
> **username_5** (2024-01-23): @feldentm Yes, e.g. you can statically determine that the field `foo` belongs to the interface `C` in the example I gave. That doesn't help when it comes to accessing the field, because `C` doesn't declare a value for the field. If you wanted it to instead resolve it to a field declared by a class which implements `C`, you would have to check the object's class at runtime, i.e. do dynamic binding.  
> **username_4** (2024-01-23): @kaya3 bind what exactly at runtime? I don't think that we talk about the same bound entity here.  
> **username_5** (2024-01-23): @feldentm The binding of the name (in this case `foo`) to the implementation of a member of that name (in this case either `A.foo` or `B.foo`). It makes no sense to statically bind the name `foo` to `C.foo`, because `C` provides no implementation of `foo` ─ interface members are abstract. If you want `c.foo` to have the value `"A.foo"` or `"B.foo"` depending on the object's runtime type, then you *must* look up the field using the object's runtime type.  
> **username_4** (2024-01-23): @kaya3 The name is statically bound to that field. That's what the IMemberKey is. Name, Type and Repr are all statically bound. The only reason why the interface exists at runtime at all is for the sake of dynamic type checking which is OT here.  
> **username_5** (2024-01-23): @feldentm Honestly I can make no sense of your position here. The fact that something has a static type doesn't mean it is statically bound. If you're looking up the field offset at runtime, based on the object's type at runtime, then you are doing dynamic binding. You might as well argue that `c.bar()` calling an interface method is also statically bound; it isn't.  
> **username_4** (2024-01-23): In Java and C# it is, in TypeScript it isnt. Only the dispatch part is dynamic. The bindings are static in the former two. I guess if you come from a scripting language, you should have a look at what really happens at runtime because that's fundamentally different. There, it is common to confuse overriding with shadowing; it could be that this is somehow creating confusion here. But those are fundamentally different things.  
> **username_5** (2024-01-23): @feldentm You seem to define static binding as *any* information about a name being known at compile-time. That is not what static binding means. Yes, the name `bar` in the expression `c.bar()` can be *resolved* at compile-time to the declaration `bar` in the interface `C`; but it cannot be *bound* to an implementation of that method until runtime, when the object's class is known. For you to claim that method calls in Java are statically bound, shows that you are not using the term in the same way as other people.  
> **username_5** (2024-01-23): On the other hand, if you must insist that (non-static, non-final) methods in Java are statically bound, then you might want to go edit Wikipedia's page about [name binding](https://en.wikipedia.org/wiki/Name_binding), which mentions Java's dynamic dispatch of methods as an example of dynamic binding.  
> **username_6** (2024-01-24): I *think* the confusion here is about what precisely is being bound statically. That is, it's between statically determining that a method call is to a particular interface method, and statically determining the function address (so to speak) that will execute at run time. The former sort of static binding of interface members *is* present in Java (e.g. overloading), and more visibly in C# where the same method signature can come from multiple interfaces and be implemented independently. This term is slightly overloaded in that way. On the other hand, fields don't need to use the same layers.  
---
### Answer by username_7 on 2024-01-23. Score: 0
It's easy to think of how it would get implemented. If the interface has a standalone vtable pointer, allocate memory after it. If it is not, calculate the offset like how vtable offsets are calculated. In the worst case, it could save the offset in the vtable, like a "virtual member variable".

You really don't need that interfaces have vtables, or allocates in any way.
An interface that defines a property requires that any implementing class to have that said storage, the same way a method defined in an interface requires that all implementing classes have a method with the same name and same signature.

Actually in the worst case, one could just use multiple inheritance. But by asking whether it is meaningful, I mean if a language supports this without much more considerations, could it still keep every advantage of single inheritance?

Yes. The compiler will only check if the implementing class defines the respective property/storage.
Note that is somewhat a niche feature, as a public mutating property is frowned upon most of the time. You may, then, emulate the annotations that are possible in get/set member functions. Something like:
interface InterfaceName {
    var PropertyName: Type { modifier; modifier; }
}

Where modifier can be one of:

Empty: non-mutating, init only;
get: can only read from this property
set: can only write to this property
get; set;: public mutating property
raw: direct access, no getter/setter


As you cited multiple inheritance, I also argue that this can cause collisions, so the language may specify a way to separate each implementation in a possibly separated block/scope, somewhat Rust's traits.
---
