[371] in Coldmud discussion meeting

root meeting help first first in chain previous in chain previous next next in chain last in chain last

Re: Changes (0.10-4)

daemon@ATHENA.MIT.EDU (Mon Jul 11 00:21:36 1994 )

From: stewarta@netcom.com (Alex Stewart)
To: BRANDON@cc.usu.edu
Date: Sun, 10 Jul 1994 21:16:42 -0700 (PDT)
Cc: coldstuff@MIT.EDU
In-Reply-To: <01HEK09N914MCU5PG2@cc.usu.edu> from "BRANDON@cc.usu.edu" at Jul 10, 94 09:21:04 pm

> set_name()    => set_objname()
> del_name()    => del_objname()
> get_name()    => get_objnum()

Umm, I thought those were going to become set_dbref(), etc..  and why is
get_name becoming get_objnum when all the others use "objname"?  Or is get_name
really a different function than I'm assuming here and not related to the

> set_heartbeat_freq() => set_heartbeat()     (this is completely aesthetic)

Cant' say I care much about this..  since it's never really seen, tho, why
bother?  (no reason to potentially break things you don't have to..)

> db_top => max_objnum()                      (ditto)

likewise, really.. but I guess this does make a little more sense (db_top could
be more specific, I suppose)..

> has_ancestor() => remove  (we can just do 'if obj in (.ancestors())', although
>                            it isn't as fast).

Ack.  no.  leave it in.  that's the kind of thing that bogs down MOO with laggy
stuff unnecessarily (compiling a list then executing several more opcodes and
searching through the whole list is much more laggy than just checking ancestry
directly and I don't see any reason why it _should_ be removed, so don't.)

> dict_add_elem()
> dict_del_elem() => remove (since they are disappearing anyway)

Fine by me.. never was really sure why these were builtins..

Oh, BTW, anybody up for creating some better buffer-mungeing builtins?
Presumably along the lines of some of the list builtins/constructs..

   Alex Stewart - stewarta@netcom.com - Richelieu @ Diversity University MOO