Not quite. Anything that continues to return user.client.Element can only be overridden to return user.client.Element or a subclass.
To pick a case at random (ahem, GXT), say you want to override UiObject.getElement for whatever reason. GWT 2.6-2.7 means that we can't change that return type, since you can't override methods and return a superclass (or a subclass of the superclass). If we assume that no downstream code ever subclasses and overrides any method that returns user.client.Element, yes, we can cut over cleanly in the future, you are right. But GXT notwithstanding, the SimplePanel class is meant to be subclassed and have getContainerElement() return a different container for the child - I'd be very surprised if there is no downstream code that does this somewhere. Example: FooLib v1 is compatible with GWT 2.5, when user.client.Element was not deprecated. It has a SimplePanel subclass called HeaderPanel, which overrides getContainerElement() to return a specific child element. GWT 2.6 deprecates user.client.Element, so FooLib v1 is compatible with both GWT 2.5 and 2.6. As it should be. To catch up, FooLib v2 would like to remove usages of user.client.Element, but since SimplePanel.getContainerElement() still requires that return type, it can't. The best they can do is find all cases of user.client.Element and cast up to dom.client.Element from the return value of methods like getElement() and getContainerElement(). Lets say GWT 2.7 cuts all user.client.Element. Now FooLib v1 and v2 are *incompatible* with GWT 2.7, even though they compatible with 2.6, and v2 was writing the cleanest possible code (returning a deprecated type). Not ideal. Or, with the patch I'm offering, GWT 2.7 keeps user.client.Element, but now has SimplePanel.getContainerElement return a supertype of user.client.Element, so subclasses are free to *further restrict* the return type (like v1/v2 is doing), or use the dom.client.Element. The v1 version will probably have issues if it uses the returned value from getContainerElement() as a user.client.Element, but v2 corrected that, so v2 now is compatible with GWT 2.6 and GWT 2.7. Win. Next, GWT 2.8 or 3.0 drops all remaining traces of user.client.Element, and since v2 didn't use it any more, in this regard v2 is also compatible with GWT 2.8/3.0. Of course, this won't happen, some other API detail will break, I promise (Splittable.removeReified, removed logger classes breaking .gwt.xml, required <resource> tags causing warnings, etc). On Wednesday, October 8, 2014 4:15:10 AM UTC-5, Thomas Broyer wrote: > > > 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/fc585406-ad63-48cf-aab5-cee69251dbdf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
