Use proper arguments in hooks

[sophialuden]

The on_enter and on_leave hooks currently use a workaround to introduce pseudo-arguments into a Code property. This should be changed to make use of the new Code (args) feature. Issue 16 may also be affected.

[erkyrath]

Why?

(Serious question. Is there an advantage? I see one disadvantage: existing hooks will all break, because they don't have an arguments line set.)

[sophialuden]

Cruft-culling. The Code (args) approach is more intuitive and therefore easier to use/document/maintain. This one thing is not much in itself, but if things like this are allowed to accumulate, then they could in aggregate become a real problem. If this project lasts long enough (and I certainly hope that it will!) then we'll almost certainly want to change this eventually, and the obvious disadvantage will only get worse over time.

A transition-easing workaround might be to automatically convert existing Code hooks to Code (args) hooks with the argument local-names automatically filled in as _from, _to. I'm not sure if the added complexity is worth keeping around long-term; it does seem like a potentially nice interface thing.

[3Phen]

Since on_enter and on_leave have fixed inputs defined by their very nature, why would you use a code(args) property, which seems designed for setting up something with custom arguments, essentially defining a function? You say it's more intuitive, but it doesn't seem that way for me. code(args) properties make sense when you're defining them entirely yourself, but hooks have a bunch of baggage, no matter how you frame them they're exceptions to some kind of pattern.

You'd have to explain to fledgling coders:

Create a code(args) property named "on_enter". This special property will be called automatically whenever a player enters the location. Unlike with other code(args) properties, you must name exactly two arguments. Name them whatever you like, but when on_enter is automatically called, the first argument will contain the "from", and the second argument will contain the "to".

It seems more straightforward this way:

Create a code property named "on_enter". This special property will be called automatically whenever a player enters the location. In this special property, temporary variables _from and _to are usable.

To me, _from and _to seem to occupy the same space as lastlocation. I have no desire to customize that, it's just a natural feature of the realm structure.

[zephjc]

Agree with @3Phen - non-callable hooks (or at least, hooks that aren't intended to be called by user-code) don't need arguments - loading vals into the hook's namespace is not an uncommon thing to do (my company's code does that for some eval'ed user-written python).

I would, however, like to see more transparency about what vars are available in the various contexts (related somewhat to #95 )