On 11/25/2010 07:13 PM, Enne Walker wrote: > 2010/11/25 Tom Lippincott<thomas.lippinc...@cl.cam.ac.uk>: >> I think SWIG could also be used to generate the "l_*.cc" files, or "fill >> them in" automatically (see below for the issue of controlling what gets >> exposed). > I would be interested to see how much cleaner this made the code. I > think the l_*.cc files are kind of messy, but most functions are often > either heavily macroified or quite custom, and in neither of those > cases SWIG would make much of a simplification. Automatically generated code is probably not going to be cleaner (e.g. you wouldn't want to sort through it by hand later on) but its reproducible, complete, and somewhat self-documenting. >> When building a Python API, I had to be selective about which structures >> were exposed: some header files caused errors that would have taken a >> longer effort to track down and fix. For the most part, you can simply >> take a header file and declare which structures you want the API to >> expose (and you get an arbitrary level of control beyond this), so its >> easy to distinguish between, say, user-accessible info and internals. > Also, I can't think of many classes that need exposing to Lua at this > point. Do you have any example of what you might consider? Given my > own experience exposing Crawl code to Lua, it felt like 95% C++ > refactoring and maybe 5% Lua glue. Again, my personal experience is with Python, but assuming it works as smoothly for Lua, there is no need for touching the C++ code in a significant way, and the glue is automatic. As for things that could be exposed, I'm interested in this from a user-script perspective: there are lots of things that aren't directly accessible from Lua, despite being legitimate player-knowledge. For example, I should be able to get the list of my current enchantments, which ones are expiring, etc, without looking for a relevant warning message. This is also related to the documentation issue: a clean approach to documenting the scripting interface (e.g. generate API docs and put them on the wiki) would be far better than going back and forth between the examples and source files! > > In both these cases of refactoring old APIs and generating new APIs, I > suspect that an example patch would make for a far more constructive > discussion. It's always more productive to talk about what's been > done than to navel-gaze about what might be done. I can try putting something together over the xmas break: how about I start on that, and let everyone know how its going in about a month, maybe send a patch around? I'd be glad to talk more about it if there are more ideas/suggestions/concerns in the meantime.
-Tom > Regards, > -enne > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! > Tap into the largest installed PC base& get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > Crawl-ref-discuss mailing list > Crawl-ref-discuss@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ Crawl-ref-discuss mailing list Crawl-ref-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
