RFE: deprecate user.client.Element and user.client.DOM
247 views
Skip to first unread message
Thomas Broyer
Dec 21, 2009, 6:10:47 PM12/21/09
to Google Web Toolkit Contributors
Hi Googlers,
How about deprecating c.g.g.user.client.Element and
c.g.g.user.client.DOM altogether and "port" all existing widgets to
c.g.g.dom.client.*?
A first "pass", say in 2.1, wouldn't break public APIs, still using
c.g.g.user.client.Element as public and protected methods' return type
and fields; only the second pass (in 2.2 or even 2.3) would completely
get rid of c.g.g.user.client.Element.
As for c.g.g.user.client.DOM, there are a few methods that have no
equivalent in c.g.g.dom.client.* (getChild/insertChild/etc. for
instance, which deal with child elements, not child nodes). Those
would have to either be moved to c.g.g.dom.client.Element or removed
altogether in the end (which means "deprecated with replacement API"
vs. "just deprecated" in the mean time).
Most widgets have complete control over their DOM, so changing from
"child element" to "child node" shouldn't break them.
I volunteer to providing patches (probably one widget at a time), but
I'd like to know upfront if I'd waste my time or if it'd have a chance
of being accepted.
Joel Webber
Jan 4, 2010, 2:02:20 PM1/4/10
to Google Web Toolkit Contributors
I think I just inadvertently replied to this on another thread, but
yes -- this is something we need to get on our roadmap very soon.
yes -- this is something we need to get on our roadmap very soon.
Colin Alworth
Oct 7, 2014, 6:55:53 PM10/7/14
to google-web-tool...@googlegroups.com
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.
Initial patch (subject to later discussion) is at https://gwt-review.googlesource.com/9514.
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.
Initial patch (subject to later discussion) is at https://gwt-review.googlesource.com/9514.
Thomas Broyer
Oct 8, 2014, 5:15:10 AM10/8/14
to google-web-tool...@googlegroups.com
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 ;-)
Colin Alworth
Oct 8, 2014, 1:11:43 PM10/8/14
to google-web-tool...@googlegroups.com
Not quite. Anything that continues to return user.client.Element can only be overridden to return user.client.Element or a subclass.
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).
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).
Thomas Broyer
Oct 8, 2014, 6:16:18 PM10/8/14
to Google Web Toolkit Contributors
On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth <nilo...@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.
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 ;-)
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.--
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 google-web-toolkit-co...@googlegroups.com.
Thomas Broyer
/tɔ.ma.bʁwa.je/
Colin Alworth
Oct 9, 2014, 12:46:38 AM10/9/14
to google-web-tool...@googlegroups.com
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 <nilo...@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.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-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 google-web-toolkit-contributors+unsubscribe@googlegroups.com.
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.
Goktug Gokdogan
Oct 9, 2014, 5:34:03 PM10/9/14
to google-web-toolkit-contributors
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.
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.--
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-co...@googlegroups.com.
Matthew Dempsky
Oct 9, 2014, 5:49:05 PM10/9/14
to google-web-toolkit-contributors
On Wed, Oct 8, 2014 at 3:15 PM, Thomas Broyer <t.br...@gmail.com> wrote:
On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth <nilo...@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.)
Goktug Gokdogan
Oct 9, 2014, 6:17:13 PM10/9/14
to google-web-toolkit-contributors
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?
--
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-co...@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.
Colin Alworth
Oct 9, 2014, 11:22:55 PM10/9/14
to google-web-tool...@googlegroups.com
commit d91ce52ae332a414a86016eb67147d732ecba95c
Author: Matthew Dempsky <mdem...@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.Author: Matthew Dempsky <mdem...@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 {
On Thu, Oct 9, 2014 at 5:16 PM, 'Goktug Gokdogan' via GWT Contributors <google-web-tool...@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).
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.
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-tool...@googlegroups.com> wrote:--On Wed, Oct 8, 2014 at 3:15 PM, Thomas Broyer <t.br...@gmail.com> wrote:On Wed, Oct 8, 2014 at 7:11 PM, Colin Alworth <nilo...@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, and2. 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-co...@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.--
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-co...@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.
Goktug Gokdogan
Oct 10, 2014, 5:49:11 AM10/10/14
to google-web-toolkit-contributors
To clarify any misunderstandings; you proposed two options and I told you the second option might not be worthwhile.
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.
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.
Reply all
Reply to author
Forward
0 new messages