Marcel Lanz (6) [Avatar] Offline
File: 5d7c50d262e0493169cbfa523de37d734e95b465 Go_in_Action_v5_MEAP_02.pdf

With 5.1 and 5.2 Use defined Types are explained. Then with 5.3.1 Embedding Types and there the Driver struct. I found it a bit confusing not to mention explicit whats the difference to a named field of type Driver might be.

Later in Listing 5.8, the license number is set twice, once with d.LicenseNumber and via tix.LicenseNumber. This could be explained.
It would be perhaps more clear to mention that these fields are transparent and also that this license number can be accessed via


could be useful.

Listing 5.9
Driver here is created as a struct literal and initialized but assigned by its address. Driver is a value type and not pointer type in Listing 5.7

Listing 5.10

Now here Driver is declared as a Pointer vs. a value type in Listing 5.7

"If you don't want a field to change through unofficial channels, you create a method"

channel might be a public field or method. perhaps something better than channel could be used.

"Now we have an embedded Driver struct inside our SpeedingTicket struct. So what? What good does this do YOU as a Go developer? Now we'll answer that question by defining methods on our user defined types."

Later in 5.4, methods are introduced but those methods are not linked with the fact, that we embedded Driver into the struct nor they change any field from Driver.

Listing 5.11
iota is not explained (also not before)

In the output, Driver is listed as:


this should be explained. Why don't we get all the embedded fields from Driver? If we would name the field explicit, then the JSON output would export the Driver as a dedicated struct.s

5.6 Serializating Your Types with JSON and XML

How about an appendinx exmaple for to explain/demo the XML serialization? for me it took a little while to get the XML namespace stuff right in the first place.