<p>I'm having trouble assigning some data to an established struct. Can I get get a little assistance or instruction? Documentation is a little light when it comes to the task I'm attempting to accomplish.
<a href="https://play.golang.org/p/jdwY1Du_eU" rel="nofollow">Playground</a></p>
<pre><code>package main
import (
"fmt"
)
func main() {
type config struct {
Storage []struct {
DiskType string
SizeGB string
MountPath string
}
Proc string
Ram string
}
systems := config{
Storage{
DiskType: "NAS",
SizeGB: "100",
},
Proc: "4",
Ram: "8192",
}
fmt.Println(systems)
}
</code></pre>
<p>Is it even possible to assign data to a struct in this manner?</p>
<hr/>**评论：**<br/><br/>dewey4iv: <pre><p>You are close. This is what I'd do: <a href="https://play.golang.org/p/HaHIXPSo9K" rel="nofollow">https://play.golang.org/p/HaHIXPSo9K</a>
<strong>edit</strong>
I might also consider using other types aside from strings. DiskType should probably be a const. Size should be int (or a different type that is an int underlying). Proc & RAM also look like ints. </p></pre>TheSp1d3r: <pre><p>Ok, so you have to separate it out by defining the inner struct. I witnessed this in the documentation, but did not know if it was a requirement.</p>
<p>This simple example you provided me helps out so much. Thank you!</p>
<p>Edit: Enjoy your gold sir ;)</p></pre>dewey4iv: <pre><p>It isn't required. But to my sensibilities it is cleaner. Sure thing, glad I could help!</p>
<p><strong>edit</strong></p>
<p>Thank you for the gold kind sir :)</p></pre>borring: <pre><blockquote>
<p>so you have to separate it out by defining the inner struct</p>
</blockquote>
<p><a href="https://play.golang.org/p/HRWe6NKlQu" rel="nofollow">here's</a> how to do it your way if you're curious. Make sure you understand Go's syntax for literals and anonymous structs.</p></pre>TheSp1d3r: <pre><p>I took your example and <a href="https://play.golang.org/p/3MWjij4ZMT" rel="nofollow">added an additional disk</a>, just to make sure I understood the structure. I realize I need to use ints, I was just trying to wrap my head around the concept, and this was the easiest example I could toss together for my purposes that did not involve fruit. :P</p></pre>dewey4iv: <pre><p>Sounds good! :) I just didn't want to leave that part out. </p></pre>baonh: <pre><p>Could you explain more about why DiskType and Size need to use another type instead of string and int? What is the benefit of it?</p></pre>scottjbarr: <pre><p>Imagine you have a slice (let's say the type is <code>[]item</code>) containing 5 <code>item</code> structs. </p>
<p>It would be weird if <code>len(items)</code> returned <code>"5"</code> (a string) instead of <code>5</code> (an integer) wouldn't it?</p>
<p>I find it useful to use strings, numbers, times etc as you would expect them to be used. So if size is a number, use an int or a float. </p>
<p>In the case of size, what if you wanted to find the disk with the largest storage? You would have to convert your string to numbers. </p>
<p>With size as a string, I could enter "I have the biggest disk in the world" and it would be valid. By using a number type for numeric values you gain a lot for free. </p></pre>baonh: <pre><p>Thanks. But looks like the question I asked was not clear. Let me ask again. My question is that for example, in case of Size, what is the benefit of using another type (with same underlying type), say <code>type size int</code>, and use like <code>type Size size</code>, instead of <code>type Size int</code>.</p></pre>scottjbarr: <pre><p>Ah, that's totally different. You'll need to decide how you want to represent your <code>Size</code> struct fields in that case. I'm not sure what the <code>size</code> type gets you. Maybe you're thinking about storing the unit in there as well ("mb", "gb" etc), but that would seem like complicating it. I'm guessing at your intentions here though.</p></pre>dewey4iv: <pre><p>Sure thing! I didn't say they needed to -- I said I might consider other types. </p>
<p>For example: A disk's size <em>is</em> a number.. why not store it as a number? By storing it as a string to lose the ability to do math against it without making conversions (that's a pain). </p>
<p>Another reason you might want to use a different type is to make your code more intelligible by using custom types that describe the API a little better. </p>
<p>Here's an example: <a href="https://play.golang.org/p/uXG3d2reD7" rel="nofollow">https://play.golang.org/p/uXG3d2reD7</a></p></pre>baonh: <pre><p>Thanks. My question should be "What is the benefit of using custom type?". Could you tell me more which cases can be used by a custom type? </p></pre>dewey4iv: <pre><p>One reason is a cleaner more expressive API. If I were to see a field on a struct labeled "size" that doesn't tell me a whole lot. Is it B? MB? GB? Whereas, a Size type that is clearly measured in bytes tells me everything I need to know. </p>
<p>It also allows for custom <code>String() string</code> methods. (see the Size type in the example).</p>
<p>I also use custom types to act as Enums. (see DiskType in the example).</p></pre>faiface: <pre><p>The only thing that you're missing (if I see right) is that the <code>Storage</code> field is a slice of structs, but you're only assigning it a single value. Plus, you're not really assigning it, because you're missing the <code>:</code> symbol there. So, you need to properly assign a slice to a slice, and that will require you to duplicate the type definition. That can be worked out by defining the inner struct outside of the outer struct as shown in the other answer.</p></pre>TheSp1d3r: <pre><p>I will have to look into what your describing and see if I can make it work from your answer as well. Thank you kind sir!</p></pre>dewey4iv: <pre><p>You aren't wrong, however, I wouldn't recommend this. I tend to prefer concrete types instead of anonymous structs. It doesn't make sense to re-define the <code>Storage</code> field every time you wanted to use it. (See here: <a href="https://play.golang.org/p/HRWe6NKlQu" rel="nofollow">https://play.golang.org/p/HRWe6NKlQu</a>). It makes more sense to me to break it out into a separate type. You end up with a cleaner instantiation of <code>config</code> and a re-useable type (<code>Store</code>).</p></pre>TheSp1d3r: <pre><p>Thanks for this, I have been playing around with this for far too long.</p></pre>
