MOO-cows Mailing List Archive
Re: $recycler, $garbage, etc
On Mon, 4 Dec 1995, Quinn wrote:
> Is there any reason to "recycle" objects (parent them to $garbage and re-use)
> other than keeping down max_object()? Is that benefit really anything but an
> aesthetic one?
Unless you use for i in [0..tonum(max_object())], which will get slower
as time goes by.
> I'm thinking I'd have a lot less trouble on my MOO if I just used built-in
> recycle() and create(): Quicker, less chance for blown creation and
> destruction routines, no book-keeping problems with re-created objects.
I still wouldn't use these inbuilts. On ghostwheel, I presume there is a
fair amount of creation/recycling going on, as is fairly common on D&D
rpg. I have found that I constantly recycle objects, and in such an
environment where it does happen, I really appreciate the safety net that
I've built into my 'destroy' verb. I do all types of things to it,
checking for verbs is the first. I NEVER recycle objects with verbs on
them. It's a nasty experience I don't wish to have. Then in addition I
check all the properties, both immediate and inherited, and, likewise,
don't recycle if any other than name and description exist.
In the case that the code decides it to be worth keeping, it just moves
the object into $dustbin, where I can examine it personally. I have a
check-database verb which runs through the entire db and checks a host of
things for me, including $dustbin.contents, and tells me if there is
anything there for me to look at.
> I'd still use the $recycler wrappers, of course, to restrict use of the
> builtins. But, I repeat in closing, is there a good functional reason
> to re-create?
I found that after having written all the above stuff, that I might as
well store it for reuse anyway.
Naturally, these arguments are quite different on the standard LambdaCore
I think the only really valid argument in favour of not using recycle()
is the first one I gave. If we wrote an inbuilt function that returned a
list of all valid objects, we might circumvent that as well. Perhaps an
even better approach is an inbuilt nextobj(curobj), which simply returns
the next largest valid object number than curobj, else #-1. That would
be more efficient memory wise, and would fit nicely inside a while loop.
Besides, that would give Irradiate a chance to use while(). *grin*
Subject Index |