[Twisted-Python] ObjectBrowser references
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
I'm the guy that had sleep-deprived reservations about what Acap was doing,
but I finally beat him^W^Wgot him to understand what I was talking about.
From: Kevin Turner
I am on the list, ya know. You don't need to CC me. :) On Sun, Nov 11, 2001 at 05:10:46PM -0500, Chris Armstrong wrote ...uh, stuff, and
I hope this all made sense (especially to Kevin, since I tried hard to get him to understand it ;)).
I tried hard to get you to me understand it too! It was like pulling teeth, but I finally got him to tell me how dividing the class and dropping the ObjectLink class was a good thing. Remember when I said I needed a portable reference to an object, "but not every object is pb.Referenceable"? The solution being: wrap the object in a pb.Referenceable. Nice. Simple. Yay.
We will also probably have an ExaminerFactory, which returns different kinds of ObjectExaminers based on what kind of object you tell it to examine (I'm not so sure we'll need ObjectExaminers, but we probably will).
"not so sure we'll need ObjectExaminers"? You meant to write
"not so sure we'll need *different kinds of* ObjectExaminers", right?
Ok, that's all I've got to say to the archive now. The rest goes to
either IRC or emacs.
--
Kevin Turner
participants (2)
-
Chris Armstrong
-
Kevin Turner