Scoped Names #13
Comments
jmert
added a commit
that referenced
this issue
Nov 13, 2023
Extend the capability of the expression generator to wrap the resulting definitions within a `baremodule`, thereby introducing a scope to isolate flag value names. This requires some mild rewiring of the macro expansion to "flip" the interpretation of the name in `BitFlagName::BaseType` to instead become the module name, and a new optional first argument adds support for choosing the actual type name (defaulting to `T`) within the module. Fixes #13.
jmert
added a commit
that referenced
this issue
Nov 13, 2023
Extend the capability of the expression generator to wrap the resulting definitions within a `baremodule`, thereby introducing a scope to isolate flag value names. This requires some mild rewiring of the macro expansion to "flip" the interpretation of the name in `BitFlagName::BaseType` to instead become the module name, and a new optional first argument adds support for choosing the actual type name (defaulting to `T`) within the module. Fixes #13.
jmert
added a commit
that referenced
this issue
Nov 13, 2023
Extend the capability of the expression generator to wrap the resulting definitions within a `baremodule`, thereby introducing a scope to isolate flag value names. This requires some mild rewiring of the macro expansion to "flip" the interpretation of the name in `BitFlagName::BaseType` to instead become the module name, and a new optional first argument adds support for choosing the actual type name (defaulting to `T`) within the module. Fixes #13.
jmert
added a commit
that referenced
this issue
Nov 13, 2023
Extend the capability of the expression generator to wrap the resulting definitions within a `baremodule`, thereby introducing a scope to isolate flag value names. This requires some mild rewiring of the macro expansion to "flip" the interpretation of the name in `BitFlagName::BaseType` to instead become the module name, and a new optional first argument adds support for choosing the actual type name (defaulting to `T`) within the module. Fixes #13.
jmert
added a commit
that referenced
this issue
Nov 13, 2023
Extend the capability of the expression generator to wrap the resulting definitions within a `baremodule`, thereby introducing a scope to isolate flag value names. This requires some mild rewiring of the macro expansion to "flip" the interpretation of the name in `BitFlagName::BaseType` to instead become the module name, and a new optional first argument adds support for choosing the actual type name (defaulting to `T`) within the module. Fixes #13.
jmert
added a commit
that referenced
this issue
Nov 13, 2023
Extend the capability of the expression generator to wrap the resulting definitions within a `baremodule`, thereby introducing a scope to isolate flag value names. This requires some mild rewiring of the macro expansion to "flip" the interpretation of the name in `BitFlagName::BaseType` to instead become the module name, and a new optional first argument adds support for choosing the actual type name (defaulting to `T`) within the module. Fixes #13.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thank you for this package. Unfortunately it has a drawback that the names for instances are not scoped. This means, for example, that it is inconvenient to use "common" names for BitFlag instances, and it is impossible to have multiple BitFlags with the same instance names. Can this package be refactored to accommodate such a structure? The implementation could be similar to that of EnumX.jl.
The text was updated successfully, but these errors were encountered: