[PEAK] peak.naming question

[Andy Gross]

I'm really liking peak.naming so far.  I've been subclassing from 
GenericPathURL and registering in peak.naming.schemes, which has 
allowed me to toss out a bunch of bug-ridden legacy config parsing 
code.

I'm at a point where I can get rid of a bunch of subclasses that only 
differ in their getObjectInstance implementation.  Each naming scheme 
allows for abbreviations in the "host" portion of the URL.  In the 
example URL "someproto://foo", "foo" references a set of configuration 
properties protocols.someproto.servers, and getObjectInstance (by 
default) should return a random choice out of that set.  I've pasted 
some example code below to illustrate.

I'd like to implement the server-picking functionality in some place 
other than the actual object who's class implements getObjectInstance - 
I'm just not sure if it should be done in the URL subclass, or if I 
should need to make a context subclass for the resolution process.  I 
suppose there are a number of ways to implement this, but I'm curious 
as to the idiomatic/proper way to do it.

Superclass:

     @classmethod
     def getObjectInstance(klass, context, refInfo, name, attrs=None):
         self = klass(context.getParentComponent(),
                      protoname=name.scheme,
                      nickname=name.user,
                      password=name.passwd,
                      port=name.port,
                      server=name.host)
         return self


Subclasses (which I'm trying to eliminate):

     @classmethod
     def getObjectInstance(klass, context, refInfo, name, attrs=None):
         self = super(IRCPresence, klass).getObjectInstance(context, 
refInfo, name, attrs)
         self.server = random.choice(self.servers[name.host])
         return self


Thanks,

/arg