On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth <niloc...@gmail.com> wrote:
> Not quite. Anything that continues to return user.client.Element can only > be overridden to return user.client.Element or a subclass. > Ha, didn't thought about subclassing w/ overriding. 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). > That's basically what I said too, right? Remove all uses of user.client.Element but keep the class around (or –better IMO– move it to a gwt-user-compat.jar) for downstream libraries. > > > 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 a topic in the > Google Groups "GWT Contributors" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/google-web-toolkit-contributors/_WCnAcsaXws/unsubscribe > . > To unsubscribe from this group and all its topics, 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 > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/fc585406-ad63-48cf-aab5-cee69251dbdf%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> -- 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/CAEayHENdj-WyQRLX%2BjQX6%2BVt_N5x_kCdDvp7ysAkdvNFDQKZrA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
