in Coldmud discussion meeting
Re: [COLD] cold stuff ;)
daemon@ATHENA.MIT.EDU (Thu Jan 2 16:55:21 1997
Date: Thu, 2 Jan 1997 14:44:47 -0700 (MST)
From: Brandon Gillespie <firstname.lastname@example.org>
> >Not really. It all depends upon what user() is for. It is simply a means
> >of identifying a 'key' controller object within the call stack, with a
> >standard interface (i.e. 'tell'). aving it default to an arbitrary
> >object could potentially break many things assuming that it always returns
> >a standard class of object (defined within the database).
> Yes, but....
> (1) None of the other similar functions (caller(),definer(), sender() )
> return a known object type. This is perfectly acceptable for this use.
> (2) I would propose that the inability to ask what the object is at the top
> of the call stack is a weakness and hole is the whole caller(),definer(),
> sender(),this() structure. This is a useful piece of information about
> the call that is totally hidden.
caller/sender/definer etc are not related to user() They are task/frame
functions. user() is not--it is simply a mechanism that MAY be used to
help a programmer track a 'controller' object througout any depth of the
task. caller/sender/etc are integral to the task/frame system, user is
irrelevant to it.
> I had an in-db thing like user() before, and dropped it for user(), but
> implemented this way there really is little additional value to it. I
> REALLY believe a function to query for top of call stack is appropriate and
> necessary (yes, one could parse traceback() but that's VERY inefficient.)
You could also parse stack(), but that is also inefficient. I'm not
really seeing what the problem is, when all you have to do is put a call
to set_user() as the first operation in $connection.parse(). Also, the
system now works well with heartbeat and the like. Should $sys be
returned as the user() when a task was called from a heartbeat? I don't
honestly see the problem with returning #-1