[Twisted-Python] ObjectBrowser references

[Kevin Turner]

So, there's been some confusion expressed (by certain
sleep-deprived individuals) about what it is that the
class twisted.python.explorer.ObjectBrowser is for.
Given that this is the first-pass implementation and
a number of questionable decisions were made in the
implementation, that's to be expected.

One train of questions goes like this:

 Q) Why is ObjectBrowser a class at all, and not just a collection of
    introspection functions?

 A) You're right, the browse_* methods make no use of an
    ObjectBrowser instance's state, and could well be static functions.
    The only reason to inXXX (what's the verb "to create an instance of
    a class"?) ObjectBrowser is so it can hold on to a consistant
    namespace.
    (See also the comment preceding the browse_ definitons for another
    reason why these methods should be gathered in a container.)

 Q) What's it doing holding namespaces?

 A) It eval()uates the identifiers (identifiying expressions, really)
    given to it in its namespace.

 Q) Ugh.  What's ObjectBrowser got to use eval() for?  Why doesn't it 
    just take an object?

And thus we arrive at the crux of the issue.

Here's my thinking:

Requirement: When an object is "browsed", the result will contain
references to other objects; it's attributes, sequence elements, etc.
It must be easy for the user to take one of those references and
browse that object.

Requirement: ObjectBrowser be usable via remote interface, i.e. PB or
web.
 
Consequence: When returning references to other objects in its results,
ObjectBrowser cannot return Python references to the objects themselves.
It must return some more "portable" reference which can freely be passed
both ways through the boundry of this Python process.

This is not the first time man has encountered such a problem; it's the
same problem Pickle faces when referencing objects "outside the pickled
data stream".  It's central to the whole concept of Perspective Broker
remote references.  It's why Glyph keeps saying we need some sort of URI
to identify objects with.
 
But not every object is pb.Referenceable, and we don't have a distributed
object URI scheme yet.  So the only way I can think of to refer to a
particular object is the way a programmer refers to the object when
speaking to the interpter -- by its identifier.  that string which, when
evaluated by the interpreter, is a reference to the object.  So that's
what ObjectBrowser returns.  ObjectLinks represeting objects with
particular identifiers.

Now we go back to the first requirement, "It must be easy for the user
to take one of those references and browse that object."  Or, as a unit
test:

    lookAtMe = SomeThing()
    
    # Look at this object.
    objectLink1 = browser.browseIdentifier('lookAtMe')
    
    # Now look at some object related to this one.
    # Simplest case: I am related to me.
    myIdentifier = objectLink1.identifier
    objectLink2 = browser.browseIdentifier(myIdentifier)
    
    # Did I get the object with the desired relation?
    # (Simplest case: Was I really me?)
    failUnlessEqual(objectLink1.id, objectLink2.id)


Now, to obtain objectLink1, you could argue that we could have used
browser.browseObject(object=lookAtMe, identifier='lookAtMe'), and you're
right.  But to obtain objectLink2, when we only have the contents of
objectLink1 to work from, we only have the identifier to pass back.

So that's why I think ObjectBrowser needs to accept identifiers,
and that's why I guess ObjectBrowser has to use eval(),

 ...

Questions, comments, reservations?
Suggestions?

-- 
Kevin Turner <acapnotic at twistedmatrix.com> | OpenPGP encryption welcome here
The moon is waning crescent, 18.2% illuminated, 25.4 days old.