MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

RE: Production release 1.8.0 of the LambdaMOO server

>> (1)  There does exist one builtin function (queued_tasks()) that behaves
>> slightly differently depending on whether it is wizard-called or not. 
>> This is a mistake from prehistory that has thus far been confined to
>> this one function.
> 
> I don't see why this is a mistake.  To me this seems like a very logical 
> and easy to remember way to make a function behave: called by a 
> non-wizard, it applies only to the caller, but called by a wizard it 
> applies to everyone.  This seems like an example of how this flexibility 
> is useful.

If my wizard bit happens to be set and I want a list of my OWN tasks, I
am just hosed --- we'll say nothing of the case where this is happens to
be LambdaMOO and someone has just launched a forkbomb.  I can't unset my
wizard bit and then do queued_tasks() ... well I could but that would
screw lots of other things.  Because of the way queued_tasks is defined
it is impossible for me to get the ordinary-player behavior for this
function, i.e., of only getting my own (wizard) tasks.  This is not what
I call flexible.

Now consider this version:

  queued_tasks()       returns a list of all tasks
  queued_tasks(PLAYER) returns a list of all tasks belonging to PLAYER

with appropriate failures if caller is nonwizard in the first case or
nonwizard-and-not-PLAYER in the second case.  Now if I see
queued_tasks(...) in some random verb, I immediately know WHOSE tasks
it's going to attempt to return and queued_tasks(me) can be counted on
to do the same thing no matter the setting of my wizard bit.  With
wrappers available one could even consider having players being able to
look at each others task queues.

It's true that @forked would now need to have `queued_tasks(player)' in
place of `queued_tasks()'.  Is it a pain to have to take an extra 2
seconds to type p-l-a-y-e-r?  Perhaps, but you only have to write that
verb once; other programmers will be needing to read it and understand
it potentially many times.  2 seconds of "flexibility" for the person
writing the verb translates to inconvenience for those who have to use
and maintain the verb.  

Not an amazingly serious problem for queued_tasks(), but it gets bad
quickly for verbs that have more complicated dependences on
caller_perms().
Home | Subject Index | Thread Index