[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Towards a more language neutral CDT
|
On Mar 8, 2005, at 3:35 PM, John Camelon wrote:
Hello Craig,
Glad to see the multi-language ball is still rolling!
I'm also happy to see others interested in this as well.
Thanks for responding.
>
> So how about this for a straw dog proposal:
>
> 1. Create a language neutral CorePlugin class, (or LangCorePlugin)
> that CCorePlugin and FortranCorePlugin can inherit from.
>
> 2. Add a static method, CorePlugin.setDefault(), that allows the
default
> to be changed at runtime, depending on context. Or maybe a better
> way would be to leave default alone (default is still CCorePlugin)
and
> add set/getCurrent().
If FDT & CDT are expected to live side by side, active in the same
workspace,
even w/natures added to the same project, setDefault() is not going to
work.
It's one huge race condition waiting to happen.
Yup.
The rationale behind having a singleton (like the ResourcesPlugin) for
our Core
and UI is that we had thought that there wasn't a need for this to be
extensible.
What would make more sense (to me, at least) is that perhaps all of
the static
registries that are assuming that everything is CNature/CPPNature
should take an
additional parameter (a nature, perhaps) that would serve as a key
into a table of sorts.
Greg and I had also kicked around something similar as well. But this
has a larger
impact on the API so we weren't sure how well it would be accepted.
Why don't we
go away and look at this carefully and come up with another proposal
along these
lines.
That being said, we need to decide as to how the extension
architecture is going to look.
Does FDT register another language/nature into the CDT or does FDT
plan to clone/own the CDT's
structure and thus wants some base classes to start out with?
Ultimately we don't believe that cloning is the answer. Hopefully we
can register an
fnature with the CDT and work from there. However, there will be some,
very language specific
stuff (parser, for instance) that needs to be separate, but this should
be a small percentage
of the code. Perhaps the Photran folk could add their perspective on
this as well.
Cheers,
Craig
