could someone check my logic?

[Nathan Smith]

Hiya,

I just wanted someone else to check this logic, because it seems really obvious, but if it were that obvious... why would it not be in lambda core by default?

Anyway, here goes:

@prop #1.parents {}

@prop #64.parents {}

@verb #1:define_parents tnt rxd

parents = {this};

p = parent(this);

while (p != #-1)

  parents = {@parents, p};

  p = parent(p);

endwhile

this.parents = parents;

return parents;

@verb $object_utils:isa2 tnt rxd

if(args[2] in args[1].parents)

return 1;

endif

Now I realise that isa2 has no error checking, and that sending it something like: $object_utils:isa2("jim", "bob") would result in a traceback, but, here are some statistics:

eval $object_utils:isa(#2, #1) :

Without the suspend_if_needed, [used 91 ticks, 0.0 seconds.]

with suspend_if_needed:  [used 100 ticks, 0.0 seconds.]

now: $object_utils:isa2(#2, #1):

[used 75 ticks, 0.0 seconds.]

I added these lines to isa2:

if(typeof(args[1])==obj&&valid(args[1]))

if(args[12] in args[1].parents)

return 1;

endif

endif

[used 84 ticks, 0.0 seconds.]

here? Or is storing parents fin a prop and using isa2 better and lambdacore floored?

Sure, 7 ticks isn't much, but if you did this verb call 100 times, 7 turns into 700. Now, I don't know about you, but running an online mud requires a lot of error checking, and isa gets used a lot. So... Just seems logical to me.

I was also going to ask why $command_utils:suspend_if_needed is called from isa, because it just seems to lag it, bu that doesn't matter too much if this theory works.

If it does work, then, enjoy! IF not, at least let me know. Thanks!

[Brendan B]

I can only vaguely speak to the logic of it, as I'm not sure how the built-in 'parent' function works, but it seems like it would be a C function that is doing a DB lookup or something that is O(1). Ticks only really represent how much time MOO code takes to execute, calling a builtin function (unless I'm wrong) only requires 1 tick to call the function, even if that function is doing a lot of work and takes a lot of time, in the C code.

One example of this is when you do is_member or 'for something in {list}'. Both of these do the same thing in the C code (though is_member lets you do case insensitive and case sensitive). They loop over {list} and check if 'something' is in it. If it's found it returns the index, if it's not found it will loop over the entire list. This is O(N) because you have an unsorted list and you are looking for a specific entry, meaning that if the list has 1000 elements in it, it will loop over all 1000 entries.

So, your solution MAY require fewer ticks, but as you have lots and lots of children, it may actually take longer to process. But... that may also be a negligible time in terms of a modern CPU. 

The big issue for me comes from the fact that your props might get out of sync with reality, especially if you're using a $recycler to recycle old objects. Might not be worth the hassle.