|
| Re: LDT and Lua Inspect [message #901721 is a reply to message #901446] |
Tue, 14 August 2012 10:25  |
 Fabien Fleutot
Messages: 2
Registered: August 2012 |
Junior Member |
|
|
Hi,
We're aware of LuaInspect indeed, but it doesn't really fit with LDT's needs.
First, it should be noted that a large part of LuaInspect is actually Metalua's parser, which is also used by LDT.
Beyond parsing, LuaInspect essentially performs variables scope analysis, and reports it as pretty-printed HTML renderings of the original source files (it also supports CSV dumps for editor integration). Its understanding of datatypes is limited, by design: it tries to keep track of functions' number of arguments, plus some simple guesses when native Lua types are used. But it won't keep track of non-native datatypes, and won't take hints when it's lost. Such a level of detail would be overkill to generate some HTML and pinpoint undeclared globals; but without it, you can't realistically hope to provide state-of-the-art autocomplete and refactoring services in an IDE.
LDT is built around a clearly defined datatype model, and supports a DSL within the comments which allows to specify type information when it can't be guessed, or when it's guessed wrong. You can't shoehorn such a model into code that was designed for a very different purpose. Besides, if you ignore parsing (done by Metalua) and HTML rendering (which we don't care about), most of the analysis performed by LuaInspect is easily expressed as Metalua treequery requests.
|
|
|
Powered by
FUDForum. Page generated in 0.03152 seconds
] 
Search
Help
Register
Login
Home
