Kristoffer,
[uplevel] doesn't help here as [self callingobject] will always return the same, whatever stack level I call it from (is this a bug or intentional?). Basically there is no way to check "caller of caller".
indeed, i checked the code behind [self callingobject] (and its like, e.g. [self callinglevel]) and it appears to me that this family is not [uplevel]-aware. If you compare with [self proc], you will find that this actually is (also in your example). I spotted the code which unwinds the hybrid xotcl/tcl callstack under [uplevel]. the patch below attached to the email fixes the behaviour and [make test] runs, but i might easily miss sth. out here.
@gustaf neumann: could you please check the patch? i also have the feeling that some refactoring can be done in XOTclCallStackFindLastInvocation(). the patch is against the git master branch (1.6.6).
in the new and rewritten callstack management and introspection for the upcoming major release, this has been solved (i checked it with your example).
Basically there is no way to check "caller of caller".
well, you already guessed in the right direction: provide a filter and manage reentrant/self-directed messages accordingly. so you could keep track of the initial caller of the caller (which is not self).
i am also not quite sure whether "the caller of the caller" makes sense in an "invocation access control" scenario, as the caller-caller was already allowed access to the object (i.e., by calling do()). so a friendclass-like approach would not need that, for instance. while a eiffel-kind of feature export would certainly do. but anyway, in xotcl, nothing is written in stone anyways :)
//stefan