Yeah, this... You can have circular dependencies, as long as it is in the implementation only. Takes some thought on interface definitions to avoid these things. Sometimes it's a real pain.
There's also the issue that when you split out units, and then you have a user who wants to consume say, a library you've written, you then have to document "Ok, to use this you have to use X, Y, and Z units for type definitions"
A better approach is to have a single "entry point" unit if you will, that simply re-declares all of the types from the X,Y,Z units, so that when you go to use the code you've written, you only have to import W, and get all the type defs already. (Hard to explain what I'm talking about I guess)
Comments
Yeah, this... You can have circular dependencies, as long as it is in the implementation only. Takes some thought on interface definitions to avoid these things. Sometimes it's a real pain.
There's also the issue that when you split out units, and then you have a user who wants to consume say, a library you've written, you then have to document "Ok, to use this you have to use X, Y, and Z units for type definitions"
A better approach is to have a single "entry point" unit if you will, that simply re-declares all of the types from the X,Y,Z units, so that when you go to use the code you've written, you only have to import W, and get all the type defs already. (Hard to explain what I'm talking about I guess)