Skip to content
New issue

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

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

Already on GitHub? # 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.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Development

No branches or pull requests

1 participant