Make @service only define a module once
#690
Conversation
Currently, `@service` defines a module every time it's called. That
works fine but the downside is that you get module redefinition warnings
if you happen to call `@service` again. The most plausible reason why
one would want to redefine the module would be to enable/disable
particular features in some region of code. To facilitate that use case
while avoiding redefinition warnings, we can `@service` check for an
existing module, define one if it can't find one, and if it can then
modify the feature set associated with the module in place. With this
change, `@service S3` (e.g.) effectively expands to:
```julia
if isdefined(Main, :S3)
AWS.set_features!(S3.SERVICE_FEATURE_SET)
else
module S3
# contents
end
end
```
The `set_features!` call uses the features specified in the macro call
as keyword arguments. No arguments uses defaults. Notably this design
requires that `FeatureSet` be made mutable, which seems fine IMO.
|
Do you have a scenario in which you want to call The only reason I can think of to support multiple |
I agree that the case this facilitates, dynamically changing the features in use for a given service, seems like an anti-pattern within a package. I'd be surprised if anybody would actually do that. The non-interactive use case I could imagine would be for folks who like to include all of their dependency loading at the top of each file in a package that utilizes those dependencies. (Not particularly common but I have seen it.)
I would consider this the primary use case. |
Currently,
@servicedefines a module every time it's called. That works fine but the downside is that you get module redefinition warnings if you happen to call@serviceagain. The most plausible reason why one would want to redefine the module would be to enable/disable particular features in some region of code. To facilitate that use case while avoiding redefinition warnings, we can make@servicecheck for an existing module, define one if it can't find one, and if it can then modify the feature set associated with the module in place. With this change,@service S3(e.g.) effectively expands to:The
set_features!call uses the features specified in the macro call as keyword arguments. No arguments uses defaults. Notably this design requires thatFeatureSetbe made mutable, which seems fine IMO.