hooks

Okay, I've looked at your code and for starters, you're making the same mistake Kozuma did by hiding the update loop from the profiler. It's not as efficient as you think it is, and as a matter of fact, what you have has the potential to be a huge performance bottleneck.

It's filled with redundancies, and it's not user friendly at all to my standard. The hooks variable ideally wouldn't be accessed directly, it should be encapsulated.

"A.hooks = list(null)" Is this you trying to clear the list...?

Okay. Let's see. Your whole library is centered around syncing variables at every tick. Why on Earth can't you just share the same reference to a datum instead? Your library has no point to it but added overhead. It isn't even practical for syncing object appearances; there are SO much better ways to accomplish this.

There's a huge problem here:


That means every atom in the world, turfs included, will have an init proc that initializes this list. Very bad idea. Instead, don't initialize your list at all; don't use [] or the new command (which are redundant together).


When you need to add a hook, only then should you create the hooks list. Likewise you should set the var to null when the last hook has been removed.

Another issue: Calling A.Del() directly is wrong. Del() should never be called directly. That should be del A instead. Ideally, it'd be even better to find a way to soft-delete A.

The global lists "special" and "active" are not well named for a library because they're likely to come into conflict with other code.

For performance reasons, special() would be best made into an associative list, at least when the library first starts up, so you can check if(special[V]) instead of if(special.Find(V)).

A.hooks.Find(src) should be replaced with src in A.hooks, since with list husbandry the A.hooks value could be null. Although I'd completely alter the datum/Del() for performance. Looping through the active list every time any object is deleted will murder your performance.