No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Calling object
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 10 Jul 2010 08:38:49 +0200
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
Date: Sat, 10 Jul 2010 08:38:49 +0200
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