This is a giant change for us and we don't have a simple way to handle that even with the tooling that we have. Let's discuss this after the release cut.
On Wed, Oct 8, 2014 at 9:46 PM, Colin Alworth <[email protected]> wrote: > On Wednesday, October 8, 2014 5:16:18 PM UTC-5, Thomas Broyer wrote: >> >> >> >> 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. >> > > Okay, call it mixed messages then. I'll update the patch to go further in > this direction, so that user.client.Element exists, but is unused in 2.7, > and we can kill it in the next version. > > Do we have a plan for a gwt-user-compat v2.7.0? Seems a bit silly to make > one for a single class... > >> >> >>> >>> >>> 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-contrib >>>>> utors/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://www.google.com/url?q=http%3A%2F%2Fxn--nna.ma.xn--bwa-xxb.je%2F&sa=D&sntz=1&usg=AFQjCNFYy-AVoPwDSnFHF0tInZW4FcsIXQ> >> > -- > 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/bce0ccc4-3e12-45f9-b60b-3bee77996685%40googlegroups.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/bce0ccc4-3e12-45f9-b60b-3bee77996685%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAN%3DyUA0y8sbfO3q3PBUCaWHw7XUNKYDVBnQazVuMuPGSkYnK4Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
