Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Proposal: embedded named inline types (type namespacing) #38245

Closed
larrycinnabar opened this issue Apr 4, 2020 · 3 comments
Closed

Proposal: embedded named inline types (type namespacing) #38245

larrycinnabar opened this issue Apr 4, 2020 · 3 comments
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Proposal

Comments

@larrycinnabar
Copy link

larrycinnabar commented Apr 4, 2020 •
edited

Go allows us to declare struct types with embedding other struct types. They can be either named or anonymous:

type Person struct {
	Name string
	Contacts Contacts 	// named embedding
	Meta struct {		// anonymous inline embedding
		Version int
	}
}

Anonymous inline embedding is useful for data-only struct when you know you won't need to add methods, and won't use these types separately as function arguments, etc.

Named embedding does a great job, you can use these structs separately and add methods to them. But I can see a minor drawback: polluting the scope with type names, so requiring of manual namespacing.

Example that highlights the problem:

type Person struct {
	Name     string
	Contacts *PersonContacts
}

type Company struct {
	Name     string
	Contacts *CompanyContacts
}

type PersonContacts struct {
	Email string
	Phone string
}

type CompanyContacts struct {
	ContactPersonName        string
	EmailSales, EmailSupport string
	Phone1, Phone2           string
}

It can be not the best example, but the idea is that we have to namespace the type names. And if level of embedding is more than 3-4 it makes ridiculously long names.

Idea behind proposal is allowing Named inline embedding. A want-to-be example:

type Person struct {
	Name     string
	Contacts *Contacts struct {
		Email string
		Phone string
	}
}

type Company struct {
	Name     string
	Contacts *Contacts struct {
		ContactPersonName        string
		EmailSales, EmailSupport string
		Phone1, Phone2           string
	}
}

// That named inline types should be fully available to be used in function args, 
// declaring own methods, etc:

func SendHelloGretting(c *Person.Contact) error {
	// send `hello`  to c.Email
	return nil
}

func (cc *Company.Contacts) Emails() []string {
	return []string{cc.EmailSales, cc.EmailSupport}
}

so here we have 4 types: Person, Company and Person.Contacts and Company.Contacts.
We can still create general type Contacts, and it won't cause any problem to *.Contacts
@larrycinnabar larrycinnabar changed the title Proporsal: embedded named inline types (type namespacing) Proposal: embedded named inline types (type namespacing) Apr 4, 2020
@gopherbot gopherbot added this to the Proposal milestone Apr 4, 2020
@mvdan
Copy link
Member

mvdan commented Apr 4, 2020

Please fill https://github.com/golang/proposal/blob/master/go2-language-changes.md - this extends Go's syntax and spec, so it definitely falls under "language change".

@mvdan mvdan added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Apr 4, 2020
@ianlancetaylor ianlancetaylor added v2 A language change or incompatible library change LanguageChange labels Apr 4, 2020
@ccbrown
Copy link

ccbrown commented Apr 5, 2020

I think this is a duplicate of #20467. There's just a very slight difference in syntax.

Overall, I'm not really a fan of the proposal, but I can sorta sympathize with it. For me, the issue isn't about the length of the names though. Long names are fine, and having to write a bit more for each type declaration is fine. But I have a hard time being consistent sometimes when it comes to name hierarchies. For example, let's say you're representing stats for a sports game:

type Stats struct {
  Players []*StatsPlayer
}

type StatsPlayer struct {
  JerseyNumber int
  Points int
}

It takes a lot of discipline sometimes to stick with hierarchical names like StatsPlayer when PlayerStats sounds more natural in most contexts. So I do think there's some merit in being able to namespace types because it makes it easier to be consistent with that sort of thing.

@larrycinnabar
Copy link
Author

@ccbrown thanks for the link. It's def is a duplicate of that issue.

And as explained here and here - not to be implemented.

Then proposal is closed.

@golang golang locked and limited conversation to collaborators Apr 7, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
5 participants
@ccbrown @ianlancetaylor @mvdan @larrycinnabar @gopherbot