|
For ObjectiveC support you will need to provide a lot of
different pieces. I try to summarize what I can think of
and hope that this is of some help for
you:
1) An
AST:
* You'll need to define all the interfaces necessary
to represent the syntax of Objective C. You
can probably
reuse the
interfaces for plain C and extend/add addtional ones as
requried.
* You need interfaces to represent
the bindings.
see packages:
org.eclipse.cdt.core.dom.ast,
org.eclipse.cdt.core.dom.ast.c
* You need an implementation for the
interfaces. Again you can probably reuse the implementation for
plain
C and add what's
needed. You will have to do your own IASTName, IASTTranslationUnit and all the
bindings
because these
interfaces return the linkage they
belong to.
see
packages: org.eclipse.cdt.internal.core.dom.parser,
org.eclipse.cdt.internal.core.dom.parser.c
2) A parser to create the
AST:
You probably want to reuse
CPreprocessor (you'll need some extensions) for preprocessing. To do the
grammar you
have the choice between
extending the LR-parser for C or extending
AbstractGnuSourceCodeParser or even GNUCSourceParser.
3) Semantics:
* Name resolution is started from
IASTName. You need to link your ast-names to the name-resolution
algorthms.
see:
CVisitor
4) Persistance:
* For your bindings you need two other
implementations: One for the pdom and one for the composite
index:
see packages
org.eclipse.cdt.internal.core.pdom.c,
org.eclipse.cdt.internal.core.index.composite.c
* Your implementation of ILinkage in
this context (extenstion to PDOMLinkage) will take care of mapping
bindings from the ast to the
index.
5) CModel:
You need to contribute a model builder for
Objective C or the existing model builder is extended to
handle
objective C,
also.
5) Editor:
Many editor features do not depend on the
ast, they use separate algorithms/scanners. I am not sure
whether the editor can be reused for
Objective C and what you need to do if it is possible, I am not an
expert
on
this matter.
6) Refactoring:
As a minimum you would need to make the
rewriter work with the extensions introduced by Objective C.
You'll
have to check for each refactoring whether
it makes sense / works for Objective C.
see
ASTWriter
expect that the refactoring code is
assuming
6) Other features: (content assist, search, navigation,
call-hierarchy, ...)
Many features are based on the ast and the
index and have a potential to work with Objective C.
However
you'll find linkage specific treatment
here or there (e.g. call-hierarchies between C and C++) and there
may
be a need to add some specific treatment
for Objective C.
In summary you will have to deal with a lot of
internals of CDT and therefore it makes sense to make ObjectiveC a part of CDT.
We will not be able to make CDT extensible such that you can add Objective C via
public API / extension points, only.
Markus.
Yeah, objective c is a superset of c and that's why I was hoping to
reuse/build upon what I could. However I'm still finding my way around the
packages and wonder how much of the .internal. is going to get in the way, to
the extent that I wonder if I'm going to have to reinvent the wheel in any
case.
Still, it's a good experiment and I'll submit what patches I can to try
and move things along, but I can't see how I can easily extend the e.g.
AbstractGNUSourceCodeParser or the KeywordSets if I needed to. And a bigger
concern is that given the PDOM isn't extendable externally coupled with the
fact that new types would be needed (protocols, selectors and so forth) that
probably makes it unlikely that autocomplete would work without changes
either.
What did you do when writing UPC? Did you just end up forking or
rewriting your own AST?
Alex
Sent from my (new) iPhone
I don't think its possible to add support for Objective-C without making
at least some minor enhancements to core CDT. For example Obj-C adds the
#import preprocessor directive. Support for that will probably have to be
added directly to CPreprocessor in CDT with a flag in
IScannerExtensionConfiguration to turn it on.
Alex, another thing
you may want to consider from the parsing side is using the LR C parser as a
base for Objective-C parsing. I used it as a base for writing the UPC
parser. I skimmed the apple docs and they say that objective-c is fully
compatible with C. So by reusing the LR C parser you get a nice chunk of
functionality for free including parsing the C subset of the language and
bindings to the CDT preprocessor. Its been designed so that extending it to
support new syntax should be easy (in theory). This is just a thought worth
considering, there may be good reasons to write a parser from scratch, I'm
not sure. And of course the AST is a different story....
Mike
Kucera
Software Developer
IBM Eclipse CDT Team
mkucera@xxxxxxxxxx
<graycol.gif>Alex Blewitt ---02/20/2009 03:38:27 PM---I'll file an
enhancement but I thought the idea of doing objc dev outside of CDT HEAD was
to avoid any objc references until su
<ecblank.gif>
From: |
<ecblank.gif>
Alex Blewitt
<alex.blewitt@xxxxxxxxx> |
<ecblank.gif>
To: |
<ecblank.gif>
"CDT General
developers list." <cdt-dev@xxxxxxxxxxx> |
<ecblank.gif>
Cc: |
<ecblank.gif>
"CDT General developers list." <cdt-dev@xxxxxxxxxxx> |
<ecblank.gif>
Date: |
<ecblank.gif>
02/20/2009 03:38
PM |
<ecblank.gif>
Subject: |
<ecblank.gif>
Re: [cdt-dev]
ILinkage? |
I'll file an enhancement but I thought the idea of
doing objc dev outside of CDT HEAD was to avoid any objc references until
such time as it had built up momentum?A bigger
concern, then, is what of the PDOM code which is all .internal. (including
some interfaces). Aren't the ILinkage and PDOM fairly coupled? They appeared
to be from my cursorary glancing. Alex
Sent from my (new) iPhone
On 20 Feb 2009,
at 08:43, "Schorn, Markus" <Markus.Schorn@xxxxxxxxxxxxx>
wrote:
You cannot add a new linkage kind
from outside of CDT. The very basic reason for that is that otherwise we
cannot maintain unique integer constants for linkages. If you need one
for ObjectiveC, we'll add it to ILinkage.
Please open an enhancement request for it.
ILinkage is no longer
marked as experimental in 6.0. I don't expect AbstractCLikeLanguage to
change either.
If you use it,
we can also make it non-experimental (just open an enhancement
request).
Markus.
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alex Blewitt
Sent: Friday, February 20,
2009 2:43 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev]
ILinkage?
Importance: Low
I'm
starting to play around with the internals of CDT, and I've come across
the following whilst creating a subclass of AbstractCLikeLanguage and
the ILinkage that's referred to from it:
AbstractCLikeLanguage:
* <strong>EXPERIMENTAL</strong>. This
class or interface has been added as
* part of a work in progress. There is no guarantee that this API will work or
* that it will remain the same. Please do not use this API without consulting
* with the CDT team.
* @since 5.0
ILinkage.java
/**
* Represents a linkage in the AST or the index.
* <p>
* <strong>EXPERIMENTAL</strong>. This
class or interface has been added as
* part of a work in progress. There is no guarantee that this API will
* work or that it will remain the same. Please do not use this API without
* consulting with the CDT team.
* </p>
* @since 4.0
*/
This seems to be defined as the set
{c,cpp,fortran} in the interface (and the implementing class is
internal). How would I go about setting up a name for Objective-C, or
can I simply return 'none' at this point? I'm somewhat playing in the
dark to get a feel of how it fits together right now, but given that it
had these in the comments I figured I'd do the honours. However, given
that CDT is working on 5.1 (at least, that's the version it shows in
Eclipse right now; 5.1.0.200902xxxx - will that be bumped to 6.0 later?)
I was wondering how experimental these things are anyway
...
Alex
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
/u> _______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
| 