RE: [cdt-dev] RE: ObjectiveC

["Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>]

Hmm, my quick trip through the PDOM class shows lots of language specific for C and C++ there. This is where we really need to start separating things out.

BTW, the ILanguage interface was intended for this kind of extensibility. We should be considering that as well.

And yes, leading up to EclipseCon is going to be very busy...

Doug.

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alex Blewitt
> Sent: Tuesday, February 24, 2009 4:24 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] RE: ObjectiveC
> 
> On Tue, Feb 24, 2009 at 3:03 PM, Schaefer, Doug 
> <Doug.Schaefer@xxxxxxxxxxxxx> wrote:
> > The vision I've always had and I'm not sure how well we 
> executed on, 
> > would be that people could easily extend the CDT with a new 
> language 
> > without having to adjust the CDT.
> 
> That would be good, if it were possible. I don't think it's 
> far off though, either.
> 
> >There are minor things like the linkage type enum that needs 
> to be in the CDT proper ...
> 
> Does this even need to be a compile-time constant? After all, 
> you already know the (presumably unique) String ID. Why not 
> persist an auto-id key along with the string at the beginning 
> of the persisted data structure? Presumably, it was to save 
> persisted space, but an int-to-string map header would allow 
> you to do both as well as allowing these to be dynamically 
> added in the future. When adding, it could consult the 
> on-disk table map and assign the next-plus-one id to the 
> entry and use that for that install. It might mean that my 
> workspace has a different concept of the IDs than yours does 
> (if I install Obj-C first, then fortran whilst you install 
> fortran then
> Obj-C) but these aren't shared anyway, right? If there are 
> shared pre-generated DOMs, these could have their own mapping 
> table defined which could get re-mapped upon merging with an 
> already on disk format.
> At least, conceptually, if not practically ...
> 
> > Part of my hesitation on this topic was whether new 
> languages should 
> > be part of the CDT or be their own project. I'm starting to 
> learn that 
> > keeping them separate isn't necessarily helping them or us.
> 
> I think there's advantages and disadvantages. For one thing, 
> sometimes it's easier to put things together externally. 
> There's also exploring what else needs to be done to make it 
> extendable so that CDT isn't a collection of everything but a 
> starting point for others to build on.
> I don't necessarily think I know what the right answer should 
> be in this case either.
> 
> > That said, if the increment is fairly minor to support Objective-C, 
> > which is very C-like, then maybe it makes the most sense having it 
> > directly in the CDT. And as the contribution becomes significant, 
> > Alex, we could nominate you as a CDT committer.
> 
> If it ever gets to that stage, great :-) But I don't think 
> I'm there yet, nor is the project. But actually, it's really 
> difficult (in a non DVCS world, at least) to keep 
> contributing changes and somewhat of an impediment to 
> contributing generally.
> 
> > To be honest, I haven't looked at language extensibility in a while 
> > and need to refresh my memory as to what's there. I've been 
> cheering 
> > Alex on in the blogosphere, and given how quickly he's 
> gotten into the 
> > issues he needs to address, it's probably a good time for 
> me to dive in.
> 
> By the way, I'm making some progress, but I'm more exploring 
> than doing at the moment. I'm not that far ahead on the 
> process yet, and expect updates leading up to EclipseCon 
> somewhat slow ;-)
> 
> Alex
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>