On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth <[email protected]> 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 > [email protected]. > 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 [email protected]. 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.
