Hi Kristoffer and all
Am 09.07.10 16:11, schrieb Kristoffer Lawson:
Now if I call [hello] from another object, I will get the object which called [hello]. Of course, if that object calls [do] instead of [hello], then [self callingobject] will end up being the same as [self]. [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?).
not sure, if it was intentional or not, but you observation is right.
the xotcl 0.* and 1.* series is based on an implementation with a private call stack (in tcl versions before the 8.5, there was no way to extend the tcl call-stack frames with oo specific client-data, tcloo needed this as well, an so tcl got it). the forthcoming 2.0 version has a unified stack (among many other things), so much behavior does not have to re-programmed in xotcl (keeping two stacks on sync).
xotcl 2.0 has this problem magically solved (stefan's patch seems fine as well for the 1.* series from the distance).
The reason I want to do this is that I have an access control system which calls something like [checkPermissions]. [checkPermissions] should just return and do nothing if the original calling object is equal to [self]. Now I end up having to passs [checkPermissions] a parameter with [self callingobject].
I am somewhat confused by your terminology. If you are looking for access control management, look for example at xoRBAC, which follows the role based access control model, standardized by the NIST http://wi.wu-wien.ac.at:8002/home/mark/xoRBAC/index.html
the basic notion in access control is based on <subject> <pred> <object> idea, which subject (individual, user) is allowed to execute which operations (pred) on which objects.
From later mails, it seems that you looking for calling-protection, where the basic question is: which object is allowed to execute which functions/methods. xotcl 2.0 has as well here some efficient built-in mechanisms to implement "static" methods, that are designed to work with the basic xotcl object model (per-class cs. per object, mixins, ...). It costs essentially no performance. This is not a strong protection, but signals maybe unwanted patterns (from a documentation and implementation point of view).
Is protection needed or not? For projects of small teams (1-2 persons), there is in my opinion very little need for that. for larger projects (10-thousands lines of code, developers with different skill levels), some mechanisms flagging the programmers intentions is useful. I was already thinking about optional mechanisms to force all methods to be static by default unless they are defined as public. This would lead automatically to classes with defined primarily interfaces, but this is still just an idea, not sure how this would work out in practice. maybe the option for this will make it into the release.
-gustaf