RE: Describing a native SDK in a sane manner.

[Dan Tull <dtull@...>]

> > Kevin Clancy [kclanc@gmail.com] wrote:
> > ... inferring these types can be extremely tricky.

> steve donovan [steve.j.donovan@gmail.com] Wrote
> In theory, impossible. Fortunately, users of an IDE do not require perfection ;)

As the primary maintainer of the IDE used by members of the various Adobe 
apps using Lua (Lightroom most notably, but there are 6 or 7 of them now) 
I've had to deal with multiple codebases that have made various style and 
API design choices and find ways to make the tools work for all* of them.

I've found sometimes it is easier and more reliable to analyze a body of code 
that uses the API instead of the implementation of the library itself.

The heuristic approach is imperfect, but tend to get smarter as the codebase
grows, and in precisely the places that are the highest traffic zones. As a bonus,
it tends to reward and reinforce a consistent style in the codebase.

One area where this helps a great deal is if the implementation of the API uses
meta-programming or native code that are harder to analyze directly.

It does mean that it is less helpful when starting a new codebase (sadly when
you need it most), but if the APIs have unit tests or sample code that is visible 
to the scanner, it'll reward you for them with better auto-completion.

I'm considered having an definition schema for dealing with cases that
are hard to automatically figure out, but so far i haven't bothered.

Dan Tull
Lua Tools Dev
Adobe

* the tools were grown within the Lightroom effort, so they were initially
quite specific to that codebase's style, but are steadily growing less so