[1202] in Coldmud discussion meeting

Re: [COLD] cold stuff ;)

daemon@ATHENA.MIT.EDU (Wed Jan 1 15:46:56 1997 )

Date: Wed, 01 Jan 1997 12:44:55 -0800
To: Brandon Gillespie <brandon@glacier.cold.org>
From: Jeff Kesselman <jeffk@ten.net>
Cc: coldstuff@cold.org

At 12:43 PM 1/1/97 -0700, you wrote:
>> 1) Did textdump ever get fixed?  Do we have a dumpsplit that works on the
>>    new format?
>
>What was wrong with the textdump?

Quite awhile ago it was broke. I just haven't kept up, is all.

>
>> 2) Is it true that user() has no useful or meaningful default before you
>>    issue a set_user()??  Wouldn't it make sense for the default value
>>    of user() to be the object that is at the top of the current call stack?
>
>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.

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.)

JK