[TransWarp] Re: dropping 'requiredInterface' from lookup() API?
Phillip J. Eby
pje at telecommunity.com
Sat Jun 8 14:13:08 EDT 2002
At 12:25 PM 6/8/02 -0400, Ty Sarna wrote:
>Phillip J. Eby wrote:
> > I think I know a better way now to accomplish your requirement for looking
> > up an address instead of an object... It would look something like this:
> > ctx = Naming.InitialContext(OBJECT_FACTORIES=)
> > reference = ctx.lookup('someURLkey')
> > 'reference' would then be an IReference object. For comparison,
> looking up
> > the actual object would look more like:
> > theObj = Naming.lookup('someURLkey')
> > The idea is that when a naming context object retrieves an IReference, it
> > passes the reference through to the object factories specified in the
> > context's environment. By default, these will be factories that convert
> > the reference into an actual object. But, by creating an initial context
> > with its object factories set to an empty list, the factory lookup will
> > find anything, so the context will simply return the IReference itself.
>OK, so this would also allow passing a different factory to get a
>different kind of interface, if that was needed for some reason?
Yep. The object factories list is similar in concept to the Python codecs
registry - a list of objects which get called with reference data, and
either return None or a converted object. So you have complete control
over what happens to references or other kinds of objects looked up from
state stored in a context. You just need a list of Naming.IObjectFactory
objects, in precedence order.
The IObjectFactory interface will have only one method,
'getObjectInstance(refInfo, name, context, environment,
attrs=None)'. 'refInfo' is the reference or object state, 'name' is the
name it was found under, 'context' is the context 'name' was looked up in,
'environment' is the context's environment, and 'attrs', if present, is the
directory attributes associated with 'refInfo'. The return value is either
the loaded/converted object, or None.
> > Unless you have any strong objections, I'm going to go ahead with this
> > approach and drop the interface argument from the API.
>Sure, I think this will work fine. I should probably read the JNDI
>tutorial so I know where all this is headed :-)
Probably not a bad idea; it's at:
At some point I'd like to write up the similarities/distinctions from JNDI,
although I find the distinctions are actually getting fewer as I go along,
since I keep finding that I can't leave out things. :) I think it's going
to end up with most of the differences simply being Pythonic idioms in
certain places to take advantage of Python capabilities like
variable-length call signatures, keyword args, and the like.
One thing that's still on my mind, designwise, is the naming of environment
properties. Historically, we've been using ALL_CAPS identifiers for
configuration values, environment variables, etc. Java uses
lowercase.dotted.property names, which is probably better from a
namespace-division point-of-view. But they're not usable as keyword
arguments, or as variables assigned in __main__... Hm. I'll probably go
with some kind of qualified-ALL_CAPS format for now, unless you have any
Oh, by the way, speaking of changes that it's your last chance to object
Jim's written up a proposal to make use of the final few "escape"
characters. This sounds like it's going to be the final word on namespace
qualification, so you might want to take a look in case you've got any
comments to get in. If we use Z3 for future projects (and don't provide
our own traversal overrides, which are actually pretty trivial to do),
we'll have URL's like: "aSpecialist/thingInTheSpecialist" vs.
"aSpecialist/@@aMethod". I'm not exactly thrilled by it, but I can
probably live with it. This is only an issue for containerish objects;
i.e. "aSpecialist/thingInTheSpecialist/thingMethod" will be fine.
Really, it's probably a non-issue since we can always add *one* traversal
method to the specialist base class and one interface to its __implements__
signature to change the rules if we don't like them.
More information about the PEAK