Re: [ jEdit-devel ] Fixing #define in C mode?

[Marcelo V. <va...@us...>]

Hi Vampire,

On 3/2/07, Vampire <Vam...@gm...> wrote:
>  I thought about that. But then I figured that is unlikely that anyone
> is actually using those classes outside of jEdit (I don't think the
> TokenMarker code is extensible, so why whould plugins use those
> classes at all?). I'll double check anyway, but I don't think it
> should be a problem.
>
>  You never know who uses it, once you published an API. ;-) I still would
> say don't change the values, it doesn't do any harm if there is a "gap"
> between the constants except that someone might wonder why there is this
> gap.

I understand that this is just a single field, that there's no problem
in maintaining it there and etc, but this brings up an interesting
point. Just because something in jEdit code is "public" should it be
declared as part of the exposed API?

The way I see it there are things in jEdit where we should try as much
as possible to maintain API compatibility. The plugin interfaces, most
classes in the "jedit" top-level package, the buffer package, the gui
package...

But for others it doesn't make a lot of sense. Things are made public
for various reasons that may have nothing to do with trying to expose
an API for others to use. I'd count in that all the classes in the
"options" package, the plugin manager classes, and why not, the syntax
package.

I think it would be healthy to have a defined set of packages that
define the "external API". So that changing things in the
"non-exported" packages doesn't need a lot of thought and checking if
we break some obscure plugin or macro.

Now, back to the subject, if no one has other comments about the
patch, I'll clean it up, make sure C/C++/Objective-C are working fine,
and check it in.

-- 
Marcelo Vanzin
mmv...@gm...
"Life's too short to drink cheap beer."