Skip to main content

[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


Back to the top