[TransWarp] Re: dropping 'requiredInterface' from lookup() API?

[Phillip J. Eby]

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 
> not
> > 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:

http://java.sun.com/products/jndi/tutorial/


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 
suggestions.

Oh, by the way, speaking of changes that it's your last chance to object 
to...  :)

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/PathNamespaceQualificationSyntax

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.