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

Allow name and group Result Tags #380

Open
jquirke opened this issue Mar 6, 2023 · 0 comments
Open

Allow name and group Result Tags #380

jquirke opened this issue Mar 6, 2023 · 0 comments

Comments

@jquirke
Copy link

jquirke commented Mar 6, 2023

Describe the solution you'd like

This is linked from an Fx feature request: uber-go/fx#998

Furthermore, it is a necessary stepping stone to another Fx feature request uber-go/fx#1036

The restriction on allowing name and group tags seems artificial. For example, this is not permitted:

type Result struct {
    dig.Out
    Foo1 Foo `name:"foo1" group:"foos"`
}

In order to populate by name and groups elsewhere.

Describe alternatives you've considered

An output dig struct can be written with multiple outputs, but that is rather clumsy.

type Result struct {
    dig.Out
    Foo1 Foo `name:"foo1"`
    Foos []Foo `group:"foos"`
}

Is this a breaking change?

Not likely. Since the desired behaviour is not currently permitted, it should not break any existing applications.

jquirke added a commit to jquirke/dig that referenced this issue Mar 6, 2023
As per Dig issue:
uber-go#380

In order to support Fx feature requests

uber-go/fx#998
uber-go/fx#1036

We need to be able to drop the restriction, both in terms of options
dig.Name and dig.Group and dig.Out struct annotations on `name` and
`group` being mutually exclusive.

In a future PR, this can then be exploited to populate value group maps
where the 'name' tag becomes the key of a map[string][T]
jquirke added a commit to jquirke/dig that referenced this issue Mar 6, 2023
As per Dig issue:
uber-go#380

In order to support Fx feature requests

uber-go/fx#998
uber-go/fx#1036

We need to be able to drop the restriction, both in terms of options
dig.Name and dig.Group and dig.Out struct annotations on `name` and
`group` being mutually exclusive.

In a future PR, this can then be exploited to populate value group maps
where the 'name' tag becomes the key of a map[string][T]
jquirke added a commit to jquirke/dig that referenced this issue Mar 6, 2023
As per Dig issue:
uber-go#380

In order to support Fx feature requests

uber-go/fx#998
uber-go/fx#1036

We need to be able to drop the restriction, both in terms of options
dig.Name and dig.Group and dig.Out struct annotations on `name` and
`group` being mutually exclusive.

In a future PR, this can then be exploited to populate value group maps
where the 'name' tag becomes the key of a map[string][T]
jquirke added a commit to jquirke/dig that referenced this issue Mar 6, 2023
As per Dig issue:
uber-go#380

In order to support Fx feature requests

uber-go/fx#998
uber-go/fx#1036

We need to be able to drop the restriction, both in terms of options
dig.Name and dig.Group and dig.Out struct annotations on `name` and
`group` being mutually exclusive.

In a future PR, this can then be exploited to populate value group maps
where the 'name' tag becomes the key of a map[string][T]
jquirke added a commit to jquirke/dig that referenced this issue Mar 7, 2023
As part of uber-go#380 we allowed names
and groups tags/options to co-exist to ultimately support Fx feature
request uber-go/fx#998.

We now intend to support Map value groups as per
uber-go/fx#1036. We will do this in 2 steps.

1. This PR will begin tracking any names passed into value groups with
out changing any external facing functionality.

2. a subsequent PR will exploit this structure to support Map value
groups.
jquirke added a commit to jquirke/dig that referenced this issue Mar 9, 2023
As per Dig issue:
uber-go#380

In order to support Fx feature requests

uber-go/fx#998
uber-go/fx#1036

We need to be able to drop the restriction, both in terms of options
dig.Name and dig.Group and dig.Out struct annotations on `name` and
`group` being mutually exclusive.

In a future PR, this can then be exploited to populate value group maps
where the 'name' tag becomes the key of a map[string][T]
jquirke added a commit to jquirke/dig that referenced this issue Mar 9, 2023
As part of uber-go#380 we allowed names
and groups tags/options to co-exist to ultimately support Fx feature
request uber-go/fx#998.

We now intend to support Map value groups as per
uber-go/fx#1036. We will do this in 2 steps.

1. This PR will begin tracking any names passed into value groups with
out changing any external facing functionality.

2. a subsequent PR will exploit this structure to support Map value
groups.
jquirke added a commit to jquirke/dig that referenced this issue Mar 9, 2023
As per Dig issue:
uber-go#380

In order to support Fx feature requests

uber-go/fx#998
uber-go/fx#1036

We need to be able to drop the restriction, both in terms of options
dig.Name and dig.Group and dig.Out struct annotations on `name` and
`group` being mutually exclusive.

In a future PR, this can then be exploited to populate value group maps
where the 'name' tag becomes the key of a map[string][T]
jquirke added a commit to jquirke/dig that referenced this issue Mar 9, 2023
As part of uber-go#380 we allowed names
and groups tags/options to co-exist to ultimately support Fx feature
request uber-go/fx#998.

We now intend to support Map value groups as per
uber-go/fx#1036. We will do this in 2 steps.

1. This PR will begin tracking any names passed into value groups with
out changing any external facing functionality.

2. a subsequent PR will exploit this structure to support Map value
groups.
jquirke added a commit to jquirke/dig that referenced this issue Mar 9, 2023
As per Dig issue:
uber-go#380

In order to support Fx feature requests

uber-go/fx#998
uber-go/fx#1036

We need to be able to drop the restriction, both in terms of options
dig.Name and dig.Group and dig.Out struct annotations on `name` and
`group` being mutually exclusive.

In a future PR, this can then be exploited to populate value group maps
where the 'name' tag becomes the key of a map[string][T]
jquirke added a commit to jquirke/dig that referenced this issue Mar 9, 2023
As part of uber-go#380 we allowed names
and groups tags/options to co-exist to ultimately support Fx feature
request uber-go/fx#998.

We now intend to support Map value groups as per
uber-go/fx#1036. We will do this in 2 steps.

1. This PR will begin tracking any names passed into value groups with
out changing any external facing functionality.

2. a subsequent PR will exploit this structure to support Map value
groups.
jquirke added a commit to jquirke/dig that referenced this issue Mar 9, 2023
As per Dig issue:
uber-go#380

In order to support Fx feature requests

uber-go/fx#998
uber-go/fx#1036

We need to be able to drop the restriction, both in terms of options
dig.Name and dig.Group and dig.Out struct annotations on `name` and
`group` being mutually exclusive.

In a future PR, this can then be exploited to populate value group maps
where the 'name' tag becomes the key of a map[string][T]
jquirke added a commit to jquirke/dig that referenced this issue Mar 9, 2023
As part of uber-go#380 we allowed names
and groups tags/options to co-exist to ultimately support Fx feature
request uber-go/fx#998.

We now intend to support Map value groups as per
uber-go/fx#1036. We will do this in 2 steps.

1. This PR will begin tracking any names passed into value groups with
out changing any external facing functionality.

2. a subsequent PR will exploit this structure to support Map value
groups.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant