Leo,
While I agree in principle, the principles lead down a path where
I'm sure no one really wants to go; it is the path paved with good
intentions.
Specific comments below.
On 24.01.2018 18:24, Leo Ufimtsev
wrote:
Yes, the point of "internal" has been hammered upon, but it's a
general point, like human rights, and of course we all agree the
humans should have plenty of those. But it strays far and wide from
the specific problem at hand. The irony of the specific problem is
apparent is when you look at the call hierarchy of the methods in
question. They're not used internally at all, unless JDT is
considered internal, which it clearly is not. As a result of JDT's
trending setting example, you'll find uses of this in any code that
tries to have really nice hover information like JDT does. Given
there bugs are open asking for it to be API, it's clear there are
clients of this specific code. Yes, they're all bad, very bad.
Of course I empathize with Lars' efforts to make improvements, and I
have in fact helped him in part with those changes, so I more than
resent arguments that I personally stand in the way of the
platform's great progress. Of course I could have been less of a
jerk in how I phrased my opinion on this specific change. Sorry for
that.
Yes, the human rights issue again. The Bugzilla record speaks for
itself though as does the call hierarchy of the methods, which makes
it clear they exist to be used outside of the project that provides
them. Had this high standard been applied to JDT, we'd not have
this problem. There simple is a double standard. Had we applied
this standard when developing Oomph, there would be no Oomph. So
while it's a high and mighty principle that one cannot argue against
without the wrath of the human rights activists protesting at your
door, it's simply not pragmatic and has not been well applied by the
overall Eclipse PMC itself.
And again, the specifics of the problem StringBuffer ->
StringBuilder; of course a trivial change, one that I can change in
two minutes in EMF, but not without maintaining my compatible
version ranges in EMF.
Yes, I see it's a significant human rights violation. But I thought
I did my part for human rights when I changed EMF's templates to
generate StringBuilder in places such as the generated toString()
method of each EClass.
I know JDT, Dani and his team, are very careful with changing
internals because they know many clients use them, and they know
that while making rapid progress is great, if they behave
disruptively because they have the intrinsic right to so so, they
could end up with fewer clients. And kudos to Dani and his team for
their consideration; EMF uses JDT internals as well and has never in
15 years been broken by any JDT internal "API" changes, even with
the changes for Java 9. It's an impressive accomplishment for the
JDT team, and I'm sure that as a whole it slows them down, but they
carefully consider the overall balance.
It's not so clear to outsiders in which direction things are moving
quickly. I don't think StringBuffer -> StringBuilder is arguably
a case in point. No one actually cares whether a toString method
uses StringBuilder as opposed to StringBuffer, but of course that
can be easily changed because no one can see that change. But
changing the signature of visible methods begs for more caution and
consideration, especially when these internals are in fact only used
externally.
Fortunately it wasn't your decision! I'd be very, very, very glad
to remove Package.getESubpackages() because it's a pointless
abomination that only ever causes problems while providing no
semantic value whatsoever. But that's really API, not "internal".
But if I wanted to be agile (and I really do!), I'd increment to EMF
3.0, and make all kinds of improvements, but the disruption to the
community would far outweigh any value that such an effort would
bring.
Conversely, if you move too disruptively, Eclipse will also die
because all kinds of tools that end users love will stop working in
Photon, so end users won't install Photon and that will make look
Eclipse bad. While you can argue (and will of course be right) that
the providers of those tools were human rights violators for using
"internal", the perception of the general users will be that Eclipse
releases are disruptive and break their tools. The users will then
look closely at what new features and improved performance they get
in return by moving to Photon, and being unable to find any that are
relevant to them, they'll shake their heads and wonder if some other
IDE might be a better alternative. In addition, the folks
developing the tools will also dread each new Eclipse release and
will wonder if it's really a good place to develop tools.
So best we all balance these highly principled issues---I do not
argue that the principles are sound---and look to make improvements
in the least disruptive way possible, accepting the fact that for
most downstream clients and for most users, having their code and
their tools simply keep working is the most important goal for
them. Of course that flies in the face of agile refactoring and
rapid progress, and of course that suggestion will set the
development teams' hair on end. But for EMF, that's something I
live with, because I know most clients, and no users, will care what
I do in EMF; they will only notice when I've done something if I
breaks them and then they'll have a bad impression of EMF. My
arguments about principles will fall deaf ears.
This would argue for applying these high standards within the
overall platform itself, so PDE should not use any internals of p2,
e.g., so "import
org.eclipse.equinox.internal.p2.director.PermissiveSlicer" in
org.eclipse.pde.internal.core.target.IUBundleContainer clearly
argues that to implement cool things in PDE one needs the highly
useful internals of p2. Similarly JDT should not use any internals
of UI, JFace, Text, and so on.
Unfortunately this is not highly pragmatic, though it does conform
to the high principles we expect all downstream clients to emulate.
If we expect downstream clients to be highly principled, the
standard needs to be set first and foremost but those arguing for
the value of those principles. Start the effort in your own back
yard, and then show to the world that all cool things can be
implemented with the public APIs with no need to use internals
across projects. When that effort is complete, climb up onto that
high horse and go on the crusade.
Unfortunately, instead of moving forward quickly, this digression
into high principles would result in the teams spending
all their
time figuring out what API clients really need in order to implement
highly-functional, cool applications. The end-effect would be that
all the clients who already have highly-functional, cool application
would be broken and would need to migrate to a new set of APIs,
which hopefully really do satisfy
all their needs.
Is this really the path down which you want to go? It is definitely
not the path down which I want to see us go, but the platform teams
sets their own path.
In EMF I have paved the path differently. In principle, "private"
is bad: if it's useful, clients will want to use it, derive from it,
and specialize it. In principle, "internal" is pointless: if it's
available clients, will definitely use it, and then when the pure,
correct, final API is realized, clients will be disrupted by the
internal -> API migration. Of course this leaves me in a bind
when I change anything, but as a counter example, one of my most
significant technical accomplishments in my career was to add
generics to the Ecore model itself in such a way that no one in my
company noticed, though EMF was used in hundreds of products. So
significant change is still possible down this other path, but yes,
it's way more restricted for me, so I fully understand that others
choose a different path. I will not argue that my path is the best
path, but it has served the majority of my client base well.
I think the middle path is the one taken by JDT, a path that
recognizes that internals are used because they can be used and
because they often need to be used. I would hope that the path
moving forward balances all such considerations.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
