kdevelop 2

[Richard Dale]

Crikey - I hope I haven't sparked off a design war! I hacked Objective-C support
into KDevelop 1.0 in about a week and didn't get too theoretical about it. All I
wanted to do was stop it seg faulting when I edited Objective-C code. I would
say adding 'elegant interfaces' for alien language support might be more work
than 'just doing it'. 

Objective-C is effectively a superset of C++, therefore adding Objective-C
support just involves extending the C++ parser, not replacing it. However, Java
support (I'm very keen on this) would involve implementing a new parser and
tokeniser. Also Objective-C uses gdb like C++, whereas Java uses jdb. I think
the greatest difficulty with Java support is the debugging side, the parsing of
the source is relatively straightforward. And I don't know how well it works
with autoconf/automake - I see there are Java .m4 macros in there in autoconf,
but I don't know what they do yet.

-- Richard

On Fri, 01 Dec 2000, you wrote:
> >From the kdevelop list, Bernd asks 
> 
> > What do you think is not ready? The earlier we get feedback about
> > it, the better the chances are that we get the necessary interfaces
> > right.
> 
> Well you know my objections. In the intervening time since we discussed this, 
> I've not changed my mind. :-)
> 
> Just briefly
> . most of the signals on kdevelcomponent need to be canned and replaced with 
> "events"
> . The kdevelopcore code is too complex. Most of this code belongs in the 
> components.
> . kdevelopcore shouldn't know anything about the modules it is loading.
> . There should be no hardwired ordering of loading modules.
> . kdevelopcore shouldn't "forward" signals to other components. This code 
> would be replaced with events anyway.
> . No actions should exists in kdevelopcore. These all belong to components. 
> (a possible _tiny_ set of exceptions will probably exist)
> 
> The question you have to ask is "How easy is it for a developer to remove an 
> existing component(s) and replace it with another". I think when you start to 
> think about those steps you may see that the framework isn't quite ready yet.
> 
> One of the problems I have in working on kdevelop2 is that I do not know what 
> the plans are for it (especially for the framework).
> 
> jbb
> 
> -
> to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
> unsubscribe your-email-address
-------------------------------------------------------

-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«