Library Generation & Client Macro API #1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added the `rusty-junctions-macro` crate as a dependency. Currently there is a `macro_rules!` macros for defining the *when* part of a Join Pattern.
Separated the patterns for each of the currently implemented join patterns into separate files. This should make future development considerably easier.
Refactored the `when!` macro to a separate crate. This will allow for the later more complex and project structure restricting procedural macros, to also be defined in this crate. All of the macros will then be re-exported to give a single dependency to `rusty-junctions`.
This macro allows for the function transformation code to be generated at compile time, for any number of arguments. This crate must be a `proc-macro` crate, meaning it has limited interoperability with other crates. Hence this structure of re-exporting.
Add the `rusty-junctions-function-transformations` crate as a dependency of `rusty-junctions-macro`, and re-export it.
Update the `function_transformation` module to use the `rusty_junctions_macro::function_transform!`.
For the imports I prefer to note the crate a single time. Then for the patterns, I have given the full path, to provide additional clarity. The patterns will be programmatically generated by the library.
The `function_types!` macro is used to programmatically generate all of the type definitions for any number of arguments.
Update the `types` module to use the `function_types!` macro. This produces a rather clean implementation, with very little repetition of similar code.
Split the controller module into a number of more specific modules. Making navigation easier, will also enable programmatic code generation to be implemented in a simpler manner.
Previously the `ControllerHandle` was defined in the `types` module. It is much more clear for it to be part of the `controller` module. Additionally, the `use` statements have been updated to reflect this.
Added the `is_alive` check to be part of the `JoinPattern` type, as it provides a simpler API. Also using a single `is_alive` check for all of the different Join Patterns - this should be considered a WIP.
This provides a much more clear API than having all of the logic contained within the controller.
Since the specific `JoinPattern` is not required, only its channels, we can use the `channels` method of the `JoinPattern` to get this information.
For easier navigation, move the `JoinPattern` to a separate module. Personally I believe having a `types` module is a code smell.
After changing the design to the new pattern we now only access the fields of the `JoinPattern` from within the same parent module. So the 'getter' methods are no longer required.
Currently this does not compile. I'm not happy with the Generic Type Parameter 'explosion' that has taken place.
Had to ensure that the `JoinPattern` trait is `Send`. I need to have another think about the design to ensure that I am not adding further constraints to the system with this design.
Currently the Clint Macro API is comprised of a number of declarative and procedural macros. Each providing varying levels of abstraction.
Client api
Renamed the `rusty-junctions-macro` crate to `rusty-junctions-library-macro`.
The `Module` struct is used in no other crate, so there is no need for the entire `rusty-junctions-utils` crate. We can include the `Module` in the proc-macro Library Generation crate.
This is the top level crate that will contain all of the functionality for the macro aspect of the project.
Refactored the Procedural Client API Macro to be part of the `rusty-junctions-macro` crate.
Refactored the Declarative Client API Macro to be part of the `rusty-junctions-macro` crate.
Refactored the `rusty-junctions-library-macro` to now be under the `rusty-junctions-macro` crate. Allows for a single dependency to be added to the `rusty-junctions` project.
Crate Organisation
A number of the functions in the public API of the `library-generation-proc-macro` crate are not used as a macro, but are instead used as functions operating on an input `TokenStream`. These definitions have therefore been removed.
Added Documentation
Allows the client to easily access the type, without being very familiar with the crate.
Improving the naming of various elements in an effort to improve clarity.
The `TypeParamIterator` can be used to construct all of the generic type parameters, upto and include the maximum pattern arity. Again this is trying to abstract information away from the macro generation and into concrete Rust types.
Fixed the `BidirPartialPattern` `impl` derive issue, that was causing patterns of an arity higher than 3 to have an issue. Also improve the general style of the code.
It is now possible to return the `Junction` when using the `junction!` macro.
The previous version did not support having the multiple generic type parameters, this version fixed this issue.
By default a name is generated for the `Junction` that is being using a 128-bit UUID. However, when the `<name> as Junction` is specified before the channel definitions, the junction will by accessible in the current scope with the given name. This is essential for ensure the macro provides equivalent functionality to the original syntax.
Re-export the `junction!` macro so that it can be accessed from any client using the `rusty-junctions` crate, without them explicitly depending on it.
To reduce complexity of the `rusty-junctions` library the two crates have been separated.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Library Generation
It is now possible for the library to be programmatically generated via a set of proc-macros to an arbitrary maximum pattern arity.
Client Macro API
Several useful macros have been produced to make using
rusty-junctionsvia its public API easier and more succinct.The
junction!macro is the main contribution here, a rather complex proc-macro imitating a closure-like syntax to define the join patterns.Crate Organisation
Due to the limitations of the current Rust Macro system, several separate crates have had to be used and published independently.
The
rusty-junctions-macrocrate is the facade providing all of the macro-based functionality torusty-junctions.