This post is part of a series where I do my best to organize my thoughts around Go: its paradigms and usability as a programming language. I write this as a Java programmer that respects the principles of Elegant Objects.

I wish to make a correction in this post. I want to focus on this statement:

Products is not a “smart” container – see point #3 in the Java proposal. You would have to manually append the newly-created Product to Products

What I meant is that clients would have to use it like this:

Let’s pay attention to this snippet:

I was really close to solving that riddle. The trick is to assign a new value to the pointer variable. The pointer variable itself is passed by value, so callers would also see the side effects. Here’s what I mean:

With this I’ve proved that Products can be made smarter: create products and dynamically append them to itself.

Several problems remain:

• Slices don’t know how to iterate themselves – only range knows that. Since this power is taken away from developers, iteration of Products is only possible with objects in memory. You cannot implement a custom iterable – like in Java – that can dynamically fetch results from a datasource.
• Since iteration is only done in memory space, deferred execution is harder to pull off. You’d basically need an abstraction for a function that returns the actual slice (think type Products func() []Product)
• Cannot be decorated. Cannot implement Premium as a slice of products because the type will have no usable attribute for this. Unless… we go back the function abstraction idea…