Another idea on how to process module dependencies... > Using the RegistryAssembly is exactly the idea I was thinking of. > Someting doesn't smell right, however, between the RegistryBuilder, > RgistyAssembly, the DescriptorParser (and its base class) ... I think > the seperation of concerns is not quite right. I've been on a path of > breaking things up into smaller and smaller pieces with greater and > greater success ... lately, I've been getting to the point where > functionality central to a single class may still be coded into a > seperate (and seprately testable) object if it isn't the contain > class' core concern. Sounds pedantic buts its actuall pragmatic. >
How about having the DescriptorParser create objects of a class DependencyDescriptor and add these to the ModuleDescriptor? This way the responsibility of checking the dependencies (by registering a post processor) could be moved to the RegistryBuilder, where it IMO makes more sense. This could also be applied to submodule processing by having the DescriptorParser add the referenced resources to the ModuleDescriptor (e.g. an addSubmoduleResource(Resource) method). Then the RegistryBuilder#processModule(ClassResolver, Resource) would parse these and the RegistryAssembly could be relieved of the responsibility of tracking submodules. Does this make sense? --knut --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
