On Thursday, September 6, 2012 10:05:02 PM UTC+2, nino wrote: > > We hit the problem while creating our libraries. > > Extending JavaScriptObject directly is not good because it restricts what > your possibilities. > So we used composition instead, giving us more power. > > So instead of > > public class MyClass extends JavaScriptObject{ > protected MyClass(){ > } > } > > maybe you should consider something like > > public class MyClass{ > protected JavaScriptObject nativePeer; > > public MyClass(){ > nativePeer = createNativeJsoObject(); > } > } > The the public API of MyClass will delegate to the JSO. > this will give you a bit more work but the API will me more flexible and > your users will thank you :). > > I once worked around this limitation by providing methods that simply cast the object into another JSO type. Example: https://code.google.com/p/gwt-in-the-air/source/browse/trunk/src/net/ltgt/gwt/air/core/client/filesystem/FileStream.java The "native" FileStream implements the IDataInput and IDataOutput interfaces (in ActionScript, which translates to "having all the same methods" in JavaScript), the FileStream cannot implement IDataInput / IDataOutput interfaces (the problem we're talking about), and in Java I cannot use multiple inheritance either. Solution: FileStream has a forInput() method that simply cast()s it to a IDataInput (a JSO type), and similarly for IDataOutput with a forOutput() method. In other cases, the methods could be called asXxx() (as in "see this object as an Xxx")
-- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/XI0F9MDMUH4J. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.