I think the other (probably bigger) problem is method overloads that has Element as the parameter type instead of return type (as that is no such thing like co-variant parameter types).
That means for whole story to work, every third-party library needs to do the same that we did in the SDK; provide two methods; one with the old type and another one with the new type. I am very skeptical that enough libraries had already did that which means all calls like thirdPartyLib.acceptsAnElement(widget.getElement()) will be broken if make the proposed change in this release. To summarize the current 'phased' plan; Everybody (GWT-SDK, third_party libs, end users) are basically required to follow this undocumented and not communicated giant plan where we are already about to move to the second phase with the proposed path. Everybody needs to update their code base twice (once to move the intermediate step and another one to get rid of existing code). And we are doing all of these, so that third-party libs will be able to have a version that is compatible with the intermediate state (which is probably already not feasible because they didn't provided second overloads as I explained above). Am I the only one who thinks this plan is infeasible so not worthwhile? On Thu, Oct 9, 2014 at 2:48 PM, 'Matthew Dempsky' via GWT Contributors < google-web-toolkit-contributors@googlegroups.com> wrote: > On Wed, Oct 8, 2014 at 3:15 PM, Thomas Broyer <t.bro...@gmail.com> wrote: > >> 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. >> > > Yeah, that was the main issue I remember being concerned about. > Thankfully covariant return types make it more manageable: as long as user > code limits itself to: > > 1. Only use com.google.gwt.user.client.Element as a return type when > needed for overloading a GWT-provided method, and > 2. In those methods, only writes return statements in the form "return > DOM.asOld(...);" > > then they'll be forwards compatible with the future GWT release that > changes the return types everywhere to com.google.gwt.dom.client.Element > (but keeps the user.client.Element subclass). > > Then finally once everyone's moved to that GWT release, user code can > change "user.client.Element -> dom.client.Element" and "return > DOM.asOld(...) -> return ..." to be forward compatible with the *next* > future GWT release that removes those APIs completely. > > (Unfortunately like Goktug mentioned, updating Google's internal code base > to meet those first two constraints is a major endeavor.) > > -- > 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/CAF52%2BS7uEwwKV-im7XbUxLkNnXkZFHcgWHjMyJH3EcCBA5GM%3DA%40mail.gmail.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAF52%2BS7uEwwKV-im7XbUxLkNnXkZFHcgWHjMyJH3EcCBA5GM%3DA%40mail.gmail.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 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/CAN%3DyUA18B6PddxH8G3R%2B9-9YQwHmhUyrVifDx5tLAXciKABXGw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
