[Import-sig] Re: Long-awaited imputil comments
Thu, 17 Feb 2000 09:20:21 -0800 (PST)
On Thu, 17 Feb 2000, Guido van Rossum wrote:
> If I have a legitimate situation (see above) where I need to change
> the policy, I want to be able to subclass one class. With the current
> architecture, I would need to subclass each of the importer classes
> that I am using to change the policy. Instead, I want to be able to
> change the ImportManager and hook it up with the existing importers.
All righty. It looks like we're in agreement on what "legitimate changes
to ImportManager" means. I'll try to capture the essence of this into some
doc/comments somewhere (definitely into doc when this is stable).
However, we still have a tension occurring here:
1) implementing policy in ImportManager assists in single-point policy
changes for app/rexec situations
2) implementing policy in Importer assists in package-private policy
changes for normal, operating conditions
I'll see if I can sort out a way to do this. Maybe the Importer class will
implement the methods (which can be overridden to change policy) by
delegating to ImportManager.
> (This also suggests that the relationship between the ImportManager
> and the _FilesystemImporter should be more loosely coupled.)
Per a suggestion from MAL, I'm going to allow a user to pass <fs_imp> at
ImportManager construction time. If you write a custom ImportManager, then
you can pass in your own fs_imp when you instantiate it. I'll also move
the default class (_FilesystemImporter) into a class variable.
Is that the uncoupling you were thinking of? (we're also uncoupling the
suffixes stuff somewhat)
Greg Stein, http://www.lyra.org/