# Production release 1.8.0 of the LambdaMOO server

Roger Crew (rfc@microsoft.com)
Tue, 12 Mar 1996 20:16:12 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    >> (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.
    >=20
    > I don't see why this is a mistake.  To me this seems like a very =
    logical=20
    > and easy to remember way to make a function behave: called by a=20
    > non-wizard, it applies only to the caller, but called by a wizard it=20
    > applies to everyone.  This seems like an example of how this =
    flexibility=20
    > 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. =20

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

    =00