Monday, June 25, 2012

More glk.h talk and some init

I've been continuing going over my "glk.h"-using library contributions, as I consider "destroying" it. For some of them, changing glk-checks to a simple-port-check makes absolutely no difference, like for boxdraw (the quote-box drawing extension), as both glk and regular simple interpreters can't use the command "locate" in the main window. The automap extension will require a bit more attention, though, as "locate" does work in the status window (which allows me to redirect the map up there), but it won't work at all in regular simple ports (like the simple DOS port), where I'll have to disallow it completely.

Another thing on my mind is how we can improve handling of the "init" routine. Despite how relatively straightforward it is, I worry that it looks like a bunch of noise to a newcomer, so if possible, I'd like to figure out a good way to compress and modularize it. Ideally, I'd like to come up with a way where including a library contribution automatically adds relevant routine calls to init so adding extensions isn't always an exercise in editing init.

Actually, just this instant, I thought of a possible answer to that. I could make a init_routines object. Each library contribution, when included, will place an object (with a property pointing to the relevant setting-up routine) inside that init_routines object. Then init could just have a routine that checks for children of the init_routines object and executes all relevant properties. I could probably also add an order priority system if it turns out that order of execution really matters (of course, order will already be set by order of inclusion, too).

Well, at some point, I'll probably throw the above together as a proof-of-concept. Hopefully, it doesn't come across as needless obfuscation to everyone else!

No comments:

Post a Comment