This would actually be a better means of handling the
_msgmacs blessing -- it would also make it much easier to
deal with not storing the _msgmacs on the owner of the
object, but rather a tertiary object.
A possible problem would be security -- what if someone
doesn't want their _msgmacs to be used? Maybe make this
rely upon @linklock?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=7718
This would actually be a better means of handling the
_msgmacs blessing -- it would also make it much easier to
deal with not storing the _msgmacs on the owner of the
object, but rather a tertiary object.
A possible problem would be security -- what if someone
doesn't want their _msgmacs to be used? Maybe make this
rely upon @linklock?
Logged In: YES
user_id=430689
_msgmacs isn't actually required for {include} is it?
You could just as easily add a optional propdir arg to it...
{include:#1,_my_mpi/,{myfunc:{&args}}}
and assume _msgmacs if it isn't specified.
Logged In: NO
Alternately, you could follow the PennMUSH method, and allow
all objects to be @parented.
Logged In: YES
user_id=48237
I agree with nobody. I actually made a suggestion for
parenting all objects before noticing this suggestion.