al3rez/gigsib

📑Golang Is Good, Structure Is Bad

Golang Is Good, Structure Is Bad

I begin with imports. Nomarlly you just import a package and the last element of the package path would be the package you want to use.

import "foo/bar/baz"

Problem

So what if there's (probably is) type called Baz and you use it:

import "foo/bar/baz"

func main() {
        baz := baz.New()
}

You just shadowed the package name with calling a variable baz and you writing baz twice baz.Baz in linguistics terms which is not good (remember DRY!) and probably you'd write a factory function called NewBaz that's even worse.

package baz

type Baz struct{}

func NewBaz() {
        // do something
}

Solution

I found a solution or trick to naming things in decent way IMO. So you just name your package whatever you want and there must be only one exported type inside the package and you should call it Type and you must separate each type into different packages and you must name packages explicitly with in PascalCase.

import Baz "foo/bar/baz"

var baz Baz.Type{}

Why?

With that trick I can use packages as metaphor to classes and you can write:

package main

import Basket "gigsib/model/basket"
import BasketItem "gigsib/model/basket_item"

func main() {
        basket := Basket.New(nil)
        basket.AddItemBang(BasketItem.New("NikeLab ACG 07 KMTR", "1100"))
        basket.AddItemBang(BasketItem.New("Nike Kobe A.D. Triple Black", "750"))
        basket.TotalPrice()
}

    require "gigsib/model/basket"
    require "gigsib/model/basket_item"

    basket = Basket.new(nil)
    basket.add_item!(BasketItem.new("NikeLab ACG 07 KMTR", "1100"))
    basket.add_item!(BasketItem.new("Nike Kobe A.D. Triple Black", "750"))
    basket.total_price()

Do you see a big difference between ruby and golang? (expect ! and naming convention and entrypoint)

gigsib's Issues

Criticism

Take this with a grain of salt, and keep in mind this is only my personal opinion.

---

import "foo/bar/baz"

var baz baz.Baz

Why would you use a global variable? You're most likely going to use a local variable inside a function, and not a global var, in most cases. And when you use a local variable, the wisdom in the go community is to keep the names short. And, if we want to use the constructor, then only one repetition would be needed:

import "foo/bar/baz"

func myFunc() {
  b := baz.New()
}

---

package baz

type Baz struct{}

func NewBaz() Baz {
        // do something
}

Yes, this is bad - especially because it's best to use just func New() Baz! When I have a function simply called New(), I generally assume that what is being created is indicated by the package name - namely, a Baz.

---

import Baz "foo/bar/baz"

var baz Baz.Type

Using this example, you are still writing baz four times (with two different capitalisations) - no improvement from the first example, which would be the """""idiomatic""""" way to do it. The quotes are there because, here again, you're using a global variable - and most variables I've declared were certainly not globals.

---

Finally, the last line you wrote in the document:

Do you see a big difference between ruby and golang? (expect ! and naming convention and entrypoint)

I don't - and that's a problem! Go is not Ruby, and Ruby is not Go. I am guessing you are a beginner to Go - and trying to bring over concepts and structures from Ruby, and that is understandable. And I'm not going to stop you if you want to use this in your Go packages - I'm just some guy on the internet with opinions. But I still think it's better to think about problems for Go in Go, not in Ruby :)

---

Finally, here's how I would do it.

shop/models/basket.go

package models

type Basket struct {
	Items []BasketItem
}

func (b *Basket) Total() (t int) {
	for _, i := range b.Items {
		t += i.Price
	}
	return
}

func (b *Basket) AddItem(i BasketItem) {
	b.Items = append(b.Items, i)
}

type BasketItem struct {
	Name  string
	Price int
}

shop/main.go

package main

import (
	"fmt"
	"shop/models"
)

func main() {
	b := &models.Basket{}
	b.AddItem(models.BasketItem{Name: "Nikelab Shoe", Price: 1337})
	b.AddItem(models.BasketItem{Name: "Triple Black Shoe", Price: 420})
	fmt.Println(b.Total())
}

Nitpicking Case Name

Small detail, but your comment on casing should probably be PascalCase since camelCase often refers to leading with a lowercase character (with capitals acting as the camel's hump).

Liked your write up BTW - curious to see if the Go community is open to exploring a new convention like this. I'm also curious what they would recommend as a workaround for the baz variable name assignment. Maybe the expectation (as an alternative to the single, lowercase letter) is to name it something contextual to its use case?