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.
