Re: Proposal: ObjectiveC parser framework

[Alexander Malmberg]

Stefan Urbanek wrote:
> Hi,
> 
> First, excuse me for a little flood today.
> 
> What do you think about extracting objective-c parsing code from
> autogsdoc into a separate framework?

afaict, autogsdoc is highly specific to extracting only the information
that it needs. I doubt that it'd be worthwhile to try to extend it much.

>  From http://wiki.gnustep.org/index.php/FrameworkWishList:
> 
> ObjectiveCParser.framework
> 
> Framework that parses Objective-C source and generates object tree
> (class interfaces, implementations, categories, methods, instance
> variables, method descriptions, class descriptions, list of required
> headers,...). It can be lossy parser, that means a code generated from
> parsed sources does not have to be the same. This framework can be
> reused, besides other apps, by:

Note that there are many ways of parsing code. Mostly, it hinges on
whether you want to parse things properly, or if you'd rather deal with
code in the form that the developer sees it. A proper parser is "better"
in the sense that it will properly parse all code, but it comes at the
price of the code not necessarily looking much like the code the
developer sees, and generating code from the parsed form is very hard or
impossible.

A crude way of classifying them would be to look at whether they run cpp
on the source or not.

>     * Gorm (importing interfaces)

Could use a proper parser if it used a few tricks, but I don't see any
significant reason why.

>     * autogsdoc (generating documentation)

Can't use a proper parser. If it did (supposing it could hook into
something to see the comments), it would miss documentation in #ifdef:d
parts. Would also break the file/class mapping, and probably cause other
problems.

>     * CodeEditor (syntax highlighting, autocompletion and variable/method
> name suggestion, method implementation/variable/class category searching,
> inteligent editing)

Can't use a proper parser. It needs to deal with code that's half-done
(and thus won't parse), and it needs to stay very close to the developer
code. Also, for performance, a parser that can run incrementally and
efficiently handle local changes would be good.

>     * Quite usable source code checkers (like one posted by andy ruder last
> time about possible memoryleak checking)

Should use a proper parser.

>     * ProjectCenter (similar to ?CodeEditor).
> 
> This framework can be also used for some Smalltalk-like class editor/browser.
> 
> This is a nice example of reusable code. What do you think?

Having a proper parser would be nice. For non-proper parsers, how to
write it depends too much on exactly what you want to do. Anyway, I
still have a gsantlr-based partially finished objective-c parser here.
Finishing it and doing something useful with it is still on my TODO
list, but not very close to the top.

- Alexander Malmberg