As the equivalent of $perm_utils:controls.
This is only useful when it's added to new server
releases... Of you'd check for the builtin to exist in
$perm_utils:controls, you'd spoil 1 tick.
$perm_utils:controls should be kept in-database since the
MOO may not use simple object ownership for control. If
anything, I'd want a patch that adds the 'controls' bifunc,
but calls it for all C-code 'controls' checks-- eg, so the
database can intercept bf_controls for all possible uses.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you think about it, if you replaced all calls to
$perm_utils:controls with the controls() builtin, you could
still allow for more complicated checks simply by overriding
the builtin. So I dunno what your problem is...
The code in controls (on top in objects.c) is exactly the
same as $perm_utils:controls, so what's the problem with
wrapping a builtin function around?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed, but there is no *benefit* provided by this patch.
While it might save CPU in the default case, in the
non-default case (which is probably more common) it would
use *more* ticks.
What I would expect for 'controls' bifunc is to move the
actual permission checks to bf_controls and have the
'controls' C function call into the MOO bifunc, thus having
set_verb_code, create, etc properly use the modified
permission system-- though in most cases, bf_set_verb_code
etc would work just as well. This would not be a trivial
patch, and you might need to rewrite major portions of code
to manage it. If someone were to tackle it, I'd revamp the
'controls' concept to include more permission controls
too... Perhaps, for example, a set of functions:
perm_can_set_property(LIST callers, OBJ what, STR/INT
property, new-value), perm_can_read_property(callers, what,
property), perm_can_set_verb_code(callers, what, STR/INT
verb, LIST new-code), perm_can_get_verb_code(callers, what,
verb), perm_can_get_verb_asm(callers, what, verb), and
perm_can_execute_verb(callers, what, verb, args).
(note, perm_can_set_verb_code would affect .program also,
not just set_verb_code)
However, even this would likely add too much overhead to
the server...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
bf_controls patch
Logged In: YES
user_id=25634
$perm_utils:controls should be kept in-database since the
MOO may not use simple object ownership for control. If
anything, I'd want a patch that adds the 'controls' bifunc,
but calls it for all C-code 'controls' checks-- eg, so the
database can intercept bf_controls for all possible uses.
Logged In: YES
user_id=1436857
What do you mean?
If you think about it, if you replaced all calls to
$perm_utils:controls with the controls() builtin, you could
still allow for more complicated checks simply by overriding
the builtin. So I dunno what your problem is...
The code in controls (on top in objects.c) is exactly the
same as $perm_utils:controls, so what's the problem with
wrapping a builtin function around?
Logged In: YES
user_id=25634
Indeed, but there is no *benefit* provided by this patch.
While it might save CPU in the default case, in the
non-default case (which is probably more common) it would
use *more* ticks.
What I would expect for 'controls' bifunc is to move the
actual permission checks to bf_controls and have the
'controls' C function call into the MOO bifunc, thus having
set_verb_code, create, etc properly use the modified
permission system-- though in most cases, bf_set_verb_code
etc would work just as well. This would not be a trivial
patch, and you might need to rewrite major portions of code
to manage it. If someone were to tackle it, I'd revamp the
'controls' concept to include more permission controls
too... Perhaps, for example, a set of functions:
perm_can_set_property(LIST callers, OBJ what, STR/INT
property, new-value), perm_can_read_property(callers, what,
property), perm_can_set_verb_code(callers, what, STR/INT
verb, LIST new-code), perm_can_get_verb_code(callers, what,
verb), perm_can_get_verb_asm(callers, what, verb), and
perm_can_execute_verb(callers, what, verb, args).
(note, perm_can_set_verb_code would affect .program also,
not just set_verb_code)
However, even this would likely add too much overhead to
the server...