To clarify any misunderstandings; you proposed two options and I told you the second option might not be worthwhile.
On Thu, Oct 9, 2014 at 8:22 PM, Colin Alworth <[email protected]> wrote: > commit d91ce52ae332a414a86016eb67147d732ecba95c > Author: Matthew Dempsky <[email protected]> > Date: Mon Sep 2 18:16:48 2013 -0700 > > Step towards eliminating com.google.gwt.user.client.Element > > This commit changes all methods that used to take a user.Element to > instead take a dom.Element, while using Node.cast() to keep the return > values as user.Element and avoid breaking callers (who might try to > assign to a user.Element variable, for example). > > During the *next release cycle*, it should be possible for users to > update their code the same way. *Then GWT can change its return > values* > to dom.Element, users can again do the same, and finally GWT can > eliminate user.Element altogether. > > Change-Id: Id793420cae4f62c39b13b6bd1b21fd3487dcd81a > > diff --git a/user/src/com/google/gwt/user/client/Element.java > b/user/src/com/google/gwt/user/client/Element.java > index a8b8ca0..de9b439 100644 > --- a/user/src/com/google/gwt/user/client/Element.java > +++ b/user/src/com/google/gwt/user/client/Element.java > @@ -23,7 +23,14 @@ package com.google.gwt.user.client; > * created from, and can be accessed in JavaScript code as expected. This > is > * typically done by calling methods in the > * {@link com.google.gwt.user.client.DOM} class. > + * > + * As of GWT 2.6, users should use {@link > com.google.gwt.dom.client.Element} > + * instead. As an *exception*, some methods still return a > <code>Element</code> > + * object for backwards compatibility (though this will change in a future > + * release), so overriding them will require returning an > <code>Element</code> > + * object too. > */ > +@Deprecated > public class Element extends com.google.gwt.dom.client.Element { > > Emphasis mine, apologies to Matthew if it feels like I am twisting any > words. > > > On Thu, Oct 9, 2014 at 5:16 PM, 'Goktug Gokdogan' via GWT Contributors < > [email protected]> wrote: > >> 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. >> > In theory, this has already been done after the GWT 2.6 release - since > user.client.Element was deprecated, it should be *expected* to be removed > in the next few releases, so excising it should be a priority. Given that > GWT minor releases already have a fair bit of API churn, it seems > *reasonable* to suggest that libraries will have other API breakage too, > and may not be able to span more than 2-4 minor GWT releases anyway. GXT > 3.1 will work with GWT 2.6.0 until GWT 2.7.x, even with this change, > because we already cleaned all cases where user.client.Element is a > parameter, and are waiting to clean return types *after* GWT does so, but > *before* user.client.Element is actually removed. Until user.client.Element > is removed, GXT 3.1 is valid. The GXT version released after > user.client.Element return types are fixed in GWT can be valid from that > point onward. > > The fact that Google hasn't kept up is the major hitch in the plan as far > as I can tell. As a downstream library, we work to keep current with latest > official release since we can't roll on using nightly builds (since our > *own* downstream users can't live with that). > >> >> 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). >> > The alternative is that for any given API breaking change, version N works > before, and version N+1 works after, but never the twain shall meet. > Keeping in mind that this happens fairly frequently, GWT versions really > should each be major, for how much breakage happens. Stepping slowly at > least makes it *possible* to have a library span multiple versions of > compatibility, and means that it isn't required that every GWT lib affected > by a break be updated a week after a GWT release. > > >> >> Am I the only one who thinks this plan is infeasible so not worthwhile? >> > > If Google was well behaved about other API breakage, I'd have a lot more > sympathy, and to be fairer than I am being, GWT 2.7 is going to be pretty > breakage-free (just the possibility of this, JSNI dispatch changes, and > AutoDirectionHandler.Target losing HasText. So far.). But GWT 2.6 added new > *final* methods to Element, ImageResourcePrototype shimmered back and > forth, repackaged apache commons in the compiler, util classes vanishing in > favor of repackaged guava. Not to mentioned > > API Changes are inevitable. Google does the lion's share of improvements to > GWT, and so guides the majority of what API changes are acceptable and > which ones are too much to handle. But stuff disappears when Google is > ready to pull it (EXPERIMENTAL comments or no), as long as Google isn't > using them and they are deemed unmaintainable. But mechanically processable > documented API changes made *over a year ago*? Too much, too soon, put it > back. > > We can have it both ways, but we need to recognize that having it both > ways is inconsistent. > > Acknowledged. Most of this is because we are trying not to fork, if we do then things would be very messy. Options are either to move as slow as the slowest moving API (for the sake for being consistent) or as quick as we can. We are choosing the second and trying to put the best work with the resources we have. On the other hand, to be fairer; Not putting experimental on something that is experimental is wrong and I already offered following deprecation process if there is anticipated usage. Also what you refer as a 'mechanically processable' change is a multi-week project that you brought up in the last minute. And also you already know that the added *final* methods were *final* because of the JSO limitations; there is no way to add methods to JSOs without a breaking change. > >> On Thu, Oct 9, 2014 at 2:48 PM, 'Matthew Dempsky' via GWT Contributors < >> [email protected]> wrote: >> >>> On Wed, Oct 8, 2014 at 3:15 PM, Thomas Broyer <[email protected]> >>> 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. >>>> >>> >>> 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 [email protected] >>> . >>> 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 [email protected]. >> 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 >> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA18B6PddxH8G3R%2B9-9YQwHmhUyrVifDx5tLAXciKABXGw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > 218.248.6165 > [email protected] > > -- > 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/CADcXZMx%2BqdsB99wAVK0J1cb%2BdbaJSLL4MvQ%2BwpDu6M_qoT_HnQ%40mail.gmail.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CADcXZMx%2BqdsB99wAVK0J1cb%2BdbaJSLL4MvQ%2BwpDu6M_qoT_HnQ%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0qStgJ%3DLK3pbOULtbSDptWSf%2Bpbk_G4ebAv_t9W%3DRF9A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
