[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] HTMLPrinter is Broken
|
| Ed,
My answers below
I think that this is the path paved with good intentions.
Sure it is. I wish for the peace in world (even if it is the road to Hell) :) We'll need to start at the bottom, in the Equinox runtime. For
example, we'll need to change a great many things in p2
before PDE works again; we'll also need to change many things in
p2 so that Oomph works again, we'll need to change a great many
things in Oomph itself so that it works again, we'll need to do a
whole heck of a lot of in JDT (likely leaving no time to make JDT
better for the end-user) and so on, and so on, until everyone on
the entire end-to-end internal food chain is exhausted. Then
we'll inflict this pain on the bad, very bad external community,
who will likely also become exhausted negotiating API before using
it. At that point we'll find out we made mistakes at the start of
the chain, and then we will ripple the next set of API changes
through the system. In a few years we'll arguably have the
world's most shining gem, the best in the world, of all possible
worlds. After all, with 20/20 hindsight we can make everything
perfect. The result will conform to all principles of greatness
beyond impeach. But more than likely we'll have little or no
community left. The users won't care at all, those that are left,
using the tools that have migrated and still actually work,
because the users won't see the underlying greatness of the
shining gem we have created. And the developers, those that are
left, will wonder if the Eclipse desktop platform is really such a
great place to target for development.
Did I make you think that we should remove all current internal API and, as such change everything / everywhere? Sorry if that is the case.
For existing internals that we don't want to change, everything should stay as is.
I suggest to not export any new internal code to prevent the phenomenon in new code. And for existing internals, I suggest to have a lightweight deprecation policy.
Finally, I suggest to have a well defined best practice about how to provide new "unstable/beta" APIs. The goal is to communicate that one can use it, but it can change anytime until they are "production ready". Currently, the best practice is to mix it up with internal code, but IMO it's a bad practice (as you said earlier, the migration from internal to API is too disruptive).
Cheers, |
Attachment:
signature.asc
Description: Message signed with OpenPGP
