On Wednesday, October 8, 2014 12:55:53 AM UTC+2, Colin Alworth wrote: > > Sorry for the thread necromancy, but aside from > https://groups.google.com/d/topic/google-web-toolkit-contributors/90PSQ7wKHtI/discussion > > this was the only relevant existing conversation I could find on the topic. > > In GWT 2.6 user.client.Element was finally deprecated, though done in a > way to avoid any backward compatibility breakage. For example, UiObject now > has two setElement methods, one for user.client.Element and another for > dom.client.Element. > > However, UiObject.getElement still returns user.client.Element, as do a > few other methods, as of master when I write these words. I'm submitting a > patch that first amends UiObject.getElement and > SimplePanel.getContainerElement to return dom.client.Element. My thinking > is that we need an API-breaking release which still holds > user.client.Element, but doesn't actually use them, allowing downstream > libraries or projects to be compatible with more than one release. > > The alternatives as I'm currently seeing them, after deprecating in an > initial release > a) force a big jump, removing all traces of user.client.Element at once, > meaning a library that is compatible with 2.x may not be compatible with > 2.x+1. Not ideal (as a downstream library author, who doesn't want to force > users to only support a single version of GWT at a time, as bugs do happen, > even in GWT), but certainly easier to maintain. > b) do this two-step dance, making API breakage twice, but with the goal of > shifting to the new API within GWT itself (and encouraging it downstream), > then a version later removing the old one. Any library/project compatible > with N is then compatible with N+1 in as many cases as possible. > > If we like b), I'd leave any static DOM methods, but dig in further and > hit any overridable methods. If a) is preferred, we can just cut to the > chase and remove user.client.Element entirely today. >
If we did things right in 2.6 (and I have no reason to think otherwise), "user code" (anything not from GWT proper, including applications and downstream libraries) can be written without any reference to user.client.Element, using dom.client.Element exclusively and never calling any deprecated method (related to Element). So after a "grace period" where downstream libraries use the same technique that GWT used in 2.6 to have both Element coexist and allow users to move entirely to dom.client.Element, I'm in favor of just removing user.client.Element. The question is how long that "grace period" should be. Whichever the deprecation policy we'll settle on (hopefully at the next SC meeting), I wouldn't oppose using a longer period for that specific case given how big a change it is. Note: for those libraries that still have to deal with user.element.Element for backwards compatibility; maybe we could remove all uses of user.client.Element in GWT but leave the class there (or move it to a gwt-user-compat.jar). Libraries could then continue to use user.client.Element for a while provided they make sure to cast all possible uses of dom.element.Element in GWT proper to user.client.Element. Or maybe I'm just wrong and it wouldn't work ;-) -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/74b4f066-a75a-4362-8c70-56e09ddf4b42%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
