On Sat, Apr 27, 2013 at 1:57 AM, Thomas Broyer <t.bro...@gmail.com> wrote:
> > > On Friday, April 26, 2013 6:59:32 AM UTC+2, Goktug Gokdogan wrote: >> >> I would like to get your feedback for fixing following issue: >> >> https://code.google.com/p/**google-web-toolkit/issues/**detail?id=4665<https://code.google.com/p/google-web-toolkit/issues/detail?id=4665> >> >> With generic Composite classes we can introduce other type-safe helper >> composites like FocusComposite or PanelComposite (see the patch). This will >> reduce boilerplate when people need to add more functionality to their >> widgets extending composite. For example >> ValueListBox<https://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/client/ui/ValueListBox.java>can >> provide all FocusWidget API by just extending FocusComposite. >> Otherwise it would have needed to add delegate for all methods in the >> FocusWidget API (20+ methods). >> Similarly, if you are developing widgets using UIBinder then you can use >> PanelComposite instead of Composite to make the widget work like a real >> panel in other templates as PanelComposite implements HasWidgets. >> >> We cannot introduce these helper classes with current Composite in a type >> safe way. The reason is initWidget can be called with any parameter and we >> can't override it to make it more specific. This issue can be easily seen >> in >> ResizeComposite<https://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/user/client/ui/ResizeComposite.java>class >> where the check need to be done in runtime. However with the proposed >> change, ResizeComposite becomes just a one liner and type is checked in >> compile time. >> >> Another minor advantage is classes extending composite will not >> necessarily need to keep a reference to the widget passed to the composite >> as getWidget will retain the type. >> > > …or cast the result of getWidget(). > > So what is the gotcha? >> >> First of all old code will give warnings due to missing generic type in >> Composite. >> > > I think we can live with this. It has (should have) no impact on the > compiled JS anyway. > When Java 5 added generics, java.util.List and java.util.Map (among others) > have been "genericized", rather than introducing TypedList and TypedMap. > That is true, though there is a small difference. List/Map are real container types. If something is a container, it is easy to justify forcing generics. The reason I was reluctant in Composite case was, usually it isn't used like a real container. In most scenarios, it is just the way to convert your UIBinder template to widget class (more about this below). > > There's only one, technically speaking, breaking change: the following > code would no longer compile as Label is not a RequiresResize, but it'd > fail at runtime anyway with the current non-generic class, so it's not a > breaking change in practice: > > public class MyComposite extends ResizeComposite { > public MyComposite() { > initWidget(new Label()); > } > } > > Also classes that doesn't need to enhance the type information will still >> need to provide a type for Composite, this includes most of the Composite >> uses with the UIBinder. >> > > What do you mean by "Composite uses with the UiBinder"? > Composite is meant to be extended, so that it's mostly an implementation > detail and you never reference the Composite type outside of the "extends > Composite" clause. > Are you using Composite differently? > There are 2 common patterns with Composite. One which is less common (but very likely was the original intention), is to hide APIs of a base class by using composition instead of extension. This is how ValueListBox works. Instead of extending Listbox, it 'composes' listbox with the help of Composite to add a new set of api/features. Similarly, if in order to develop a new widget that uses FlowPanel as starting point, now you no longer need to extend FlowPanel which would have cause you to inherit and expose all the API. In libraries like Swing, this was a huge pain. In GWT, you can use a Composite and hide FlowPanel APIs. In this case, it makes sense to have Generics as the type the delegate object (i.e. the widget passed to initWidget) has significance. Also you are more likely need to forward more APIs, hence classes like FocusComposite, PanelComposite makes sense. A small implication to note here is, now the base class extending composite, will start exposing its delegate type to child classes. i.e. when ValueListBox extends Composite<ListBox> and if it is not a final class, it needs to keep that type forever. The second scenario is developing a "view" with UIBinder (most of the user code) where there is a template and developer tries to convert it into a GWT Widget. In these scenarios, usually, the root element in the template is insignificant (the first type in UIBinder generics) and java code doesn't really care. We will be forcing a type to be defined for the composite. > >> We can get mitigate these problems by introducing a separate >> 'TypedComposite' and 'TypedResizeComposite' class that uses generics. Of >> course this means more classes that will potentially cause more confusion. >> >> Anyway I uploaded following patch so you can take a look how things will >> look like with TypedComposite: >> >> https://gwt-review.**googlesource.com/#/c/2582/<https://gwt-review.googlesource.com/#/c/2582/> >> >> Let me know what you think. >> > > IMO we should just make Composite and ResizeComposite generic. > > I'm tend towards that but I want to be sure pros/cons to be understood well and we didn't miss anything before moving forward. > -- > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "Google Web Toolkit Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
