This PR makes several adjustments to the ongoing location set project.
Macros
macro_export exports the macro under the root crate. In our case, LocationSet! was qualified as chorus_lib::LocationSet. However, the LocationSet macro should be part of the core module. There is no way to achieve this in the current Rust ecosystem, but the common workaround is to give the macro a different internal name and re-export it from the module. I applied this workaround to LocationSet.
Separate builder structs
This PR separates the builder struct for LocalTransportChannel and TransportConfig.
As discussed, if we apply the builder pattern on LocalTransportChannel itself, we have to construct new hashmaps again and again. While this is not a big problem for now, I want to explore other design options.
One option is to create a separate builder struct, accumulate information on that struct, and call build that produces the desired data type at the end. This allows us to have separate code for accumulating information vs. instantiating the final struct.
Because it can be confusing to mix the two styles (calling methods directly on the struct / using the separate builder struct), I changed both LocalTransportChannel and TransportConfig to the latter style.
This PR makes several adjustments to the ongoing location set project.
Macros
macro_exportexports the macro under the root crate. In our case,LocationSet!was qualified aschorus_lib::LocationSet. However, theLocationSetmacro should be part of thecoremodule. There is no way to achieve this in the current Rust ecosystem, but the common workaround is to give the macro a different internal name and re-export it from the module. I applied this workaround toLocationSet.Separate builder structs
This PR separates the builder struct for
LocalTransportChannelandTransportConfig.https://github.com/lsd-ucsc/ChoRus/pull/14#discussion_r1339563114
As discussed, if we apply the builder pattern on
LocalTransportChannelitself, we have to construct new hashmaps again and again. While this is not a big problem for now, I want to explore other design options.One option is to create a separate builder struct, accumulate information on that struct, and call
buildthat produces the desired data type at the end. This allows us to have separate code for accumulating information vs. instantiating the final struct.Because it can be confusing to mix the two styles (calling methods directly on the struct / using the separate builder struct), I changed both
LocalTransportChannelandTransportConfigto the latter style.