[Xotcl] Calling object

[Gustaf Neumann]

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