-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion to remove circular module dependency #3
Comments
Hm... the point of traits is to ask questions about the types of things. The point of types is to define the types. Now, it doesn't need to be really split this way, but I rather like the idea of the semantic separation. Of course, this means Can you disclose what the build system this is, and why it is important? I am not 100% married to this split of the module semantics, and am certainly willing to either combine or compromise here. There was no "deep deliberation" in how to split up the symbols between modules. But D usually does pretty well at circular dependencies.... |
Yes - I felt that the patch might not align with your intentions. The build system is a custom one that enforces a strict dependency relationship (no circular dependencies), which eliminates a range of build issues. My codebase is a mix of D and c++, hence the build system approach. (I do not like dub!) |
I'm thinking I will think about this some more, and see if I can eliminate the circular dependency. |
To be honest, this part of the code was kind of hacky. What I was trying to do is reproduce some serialization mechanisms I had in a previous serializer project that did this kind of thing. I'm also open to suggestions on how this might be done better. |
There is a circular module dependency between traits.d and types.d that does not look like it needs to be there (the build system I use is very strict on this). The following patch removes it, but it may not be in line with the original intentions.
The text was updated successfully, but these errors were encountered: