<p>Like so :</p>
<pre><code>type someInterface interface {
someFunc() string
someVar int
}
</code></pre>
<p>I think it would make the language a lot more powerfull, or atleast coding something would be nicer. You wouldn't have to type switch just to use some variables that are in every one of your objects/structs</p>
<hr/>**评论：**<br/><br/>peterbourgon: <pre><p>Interfaces are behavior contracts, not classes or structs. Data has no place in them.</p></pre>DualRearWheels: <pre><p>dotGo 2015 - Rob Pike - Simplicity is Complicated</p>
<p><a href="https://youtu.be/rFejpH_tAHM" rel="nofollow">https://youtu.be/rFejpH_tAHM</a></p>
<p>"interfaces are just set of methods.. people ask for variables there too all the time.. they ain't gonna get them"</p></pre>sabi0: <pre><p>Well damn he's honest about that</p></pre>DualRearWheels: <pre><p>I guess adding them would defeat the intended purpose of interfaces, and they have given far more thought about it (and effect on delicate balance/interaction with the rest of the language) than you, me and all people on this thread combined.</p>
<p>People should first read about Go history, problems it tries to solve and its design evolution, it is fascinating read (I spent on it 2 weeks before I started to learn the language itself).
All the features, trade-offs and "limitations" I found later were in line with stated purpose and design goals. I don't have any major complain - they said they want to build something, they built it as they said it.</p>
<p>And then some people come, don't know or want to know about its goals, and ask for kitchen sink because every other kitchen has it. /rant</p>
<p>Read its history first, people.</p></pre>Killing_Spark: <pre><p>If its only a few variables, do something like getX() in your interface. </p></pre>CritJongUn: <pre><p>Isn't that a bit useless?</p>
<p>Unless you do some kind of transformation to the data, a get method is redundant since the struct variables are public. Also as said by <a href="/u/peterbourgon" rel="nofollow">/u/peterbourgon</a></p>
<blockquote>
<p>Interfaces are behavior contracts, not classes or structs. Data has no place in them.</p>
</blockquote>
<p>Supported by <a href="/u/DualRearWheels" rel="nofollow">/u/DualRearWheels</a> - <a href="https://youtu.be/rFejpH_tAHM" rel="nofollow">dotGo 2015 - Rob Pike - Simplicity is Complicated</a></p></pre>Killing_Spark: <pre><p>In a sense, providing a value is behaviour. And if he has massive amounts of typeswitching for one or two variables its kinda worth it. </p></pre>patrickdlogan: <pre><p>This would force interfaces to behave significantly different from the way they do in Go 1.x</p>
<p>Let's say you have a struct S that implements an interface I and that interface defines a variable V.</p>
<p>When S is used in a place defined as an I for the first time, where does the value for V cone from? When that use of S as an I is no longer in scope, how does the value for V get preserved until the next use of S as an I?</p>
<p>Whatever the merits of this proposal, it is at odds with Go 1.x interfaces. At best this would have to be a new kind of mechanism that would replace interfaces altogether or would have to exist alongside the current interface mechanism.</p>
<p>Seems like a showstopper.</p></pre>epiris: <pre><p>The main issue is you are enforcing more than behavior with this type of an interface. You're also defining mutability and thread safety. With interfaces if you want to add locking in front of a existing interface it's easy to wrap it with a Mutex, this pattern would be impossible with fields. I imagine most of the time you would want a group of fields in a interface, a better design would be a State() method that returns a snapshot of the fields you want to expose. Replacing state with something more appropriate to whatever it is. You could always have a Save method on the State struct to handle thread safe saving or a Update(s State) error method in the interface to commit it to the object. </p></pre>dilap: <pre><p>I disagree; an interface is really saying, "I need this to do something, <em>how</em> it's done I don't care about."</p>
<p>Specifying a variable is specifying <em>how</em>, which runs contrary to the spirit of interfaces.</p>
<p>The workaround is quite simple:</p>
<pre><code>int GetSomeVar()
SetSomeVar(int)
</code></pre>
<p>Getters and setters aren't always evil, just usually. ;-)</p></pre>Sythe2o0: <pre><p>If it's a lot of variables, this is what I do:</p>
<pre><code>type A struct {
c,d,e,f,g....
}
type B interface {
GetA() *A
}
func (a *A) GetA() *A {
return a
}
</code></pre>
<p>Then anything composed of <code>A</code> can be used as a <code>B</code> to give easy access to the variables</p></pre>
