[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [xtext-dev] API Tooling
|
here is a note I received from Chris on that topic:
There is no need to "tag" public API... it's simple in Equinox. All
packages that aren't x-internal or x-friends are API.
The model is that you have some control over things that may be API
but aren't meant to be extended, implemented or referenced.
Does that make sense?
It might make sense in many scenarios.
However, we want to technically allow use of non-public API, therefore
we've to export more than just the stable stuff.
We want to mark some of the exported interfaces, classes explicitly as
stable, so the user can be sure that we won't do any breaking changes
there.
On 10.02.2009, at 09:32, Sebastian Zarnekow wrote:
basically I'ld like to declare API as public instead of probiting
usage of all these nice interfaces, classes and methods that we
created, because we can and will not guarantee that they won't
change in the next milestone.
This sounds like a perfect fit for marking them as @noimplement /
@noextend.
Yes, I also think that these tags are nice and useful in addition to
something like a @stable tag.
The main problem is, that most of our interfaces are likely to
change over time, but this is expected. However clients should be
allowed to use them without any problem (-markers).
I object, as IMO it is essential we tell users exactly which
interfaces we expect to change over time. This will save them all
the hassle of reworking their code when we release a new version of
Xtext.
That's what Sebastian says, the only difference is that he wants to
tag what's stable as opposed to what's not.
In general, I'ld prefer to focus on collecting and discussing what's
stable instead of starting yet another tool discussion.
I'm fine with using the API Tooling tags in addition to general life
cycle tags (@deprecated, @stable).
Cheers,
Sven
