commit d91ce52ae332a414a86016eb67147d732ecba95c
Author: Matthew Dempsky <mdemp...@google.com>
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 <
google-web-toolkit-contributors@googlegroups.com> 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.
> 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
> <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
niloc...@gmail.com
--
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/CADcXZMx%2BqdsB99wAVK0J1cb%2BdbaJSLL4MvQ%2BwpDu6M_qoT_HnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
