Richard_Dale at tipitina.demon.co.uk
Sat Dec 2 23:51:01 UTC 2000
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.
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
> . The kdevelopcore code is too complex. Most of this code belongs in the
> . 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).
> 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:
More information about the KDevelop-devel