Hi nino, i'm making a second Java API for my yuigwt project, on top of my 
JSO based Java API, wrapping JSO objects and delegating methods to it. I 
have a couple of questions for you about this. I'm not sure, perhaps the 
best is to create another thread for this questions, but here they go: 

I have a rich class hierarchy for example, ClassC extends ClassB extends 
ClassA

Now for ClassA I'm writing: 

public class ClassA {
protected JSOClassA _wrapped; 
}

The problem is that in ClassB and ClassC I must cast _wrapped to JSOClassB 
and JSOClassC for implementing method delegation, so I ended with something 
like

public class ClassB extends ClassA {
  protected JSOClassB _wrappedClassB() {
    return _wrapped.cast(); 
  }
}
public class ClassC extends ClassB {
  protected JSOClassC _wrappedClassC() {
    return _wrapped.cast(); 
  }
}

can you think of another more simpler way to solve this ? 

And the other question is, how or where should I initialize the _wrapped 
field ? at constructor ? 

Regards and thanks in advance. 

On Tuesday, September 11, 2012 7:24:56 AM UTC-3, nino wrote:
>
> Answer below in Bold.
>
> Cheers
>
> 2012/9/11 Sebastián Gurin <sebast...@gmail.com <javascript:>>
>
>> Nino; I very like your thoughts and I agree with them. My reply between 
>> lines: 
>>
>> On Monday, September 10, 2012 5:05:25 PM UTC-3, nino wrote:
>>>
>>> The main Question is do you want YUI users to use Java or do you want 
>>>  to bring Java Devs to YUI ? 
>>> I think you will get more traction by choosing the latter.
>>>
>>>
>> I also thought of that. I started learning how to port JavaScript 
>> libraries to GWT  with my project http://code.google.com/p/raphael4gwt/, a 
>> vector drawing library. As such, performance was a requirement, and 
>> then a Java API using  GWT overlays directly was a requirement. But now for 
>> YUIGWT I wonder if that is true. Some notes: 
>>
>
>
>         *Yeah overlay type can be inherited but there is not much u can 
> do with that.Plus the methods beeing all finals one cant override them. Not 
> really flexible imho*. 
>
>>
>> 1) overlay types CAN be inherited, but I agre that is very unconfortable 
>> for end GWT/Java users to do this... this is a very important  "issue" in 
>> my project I think...
>> 2) I very liked your question: "do you want YUI users to use Java or do 
>> you want  to bring Java Devs to YUI ? " and it is making me reflect a lot. 
>> thanks. 
>>  
>>
>>> While a zero overhead API gives you the ability to  easely write YUI 
>>> code in java soon you will get users request  like "Why cant i extends 
>>> class X to add my own functions". Overlay types dont give you.
>>>
>>> We had this problems while implementing our libraries. We started first 
>>> with 1:1 match of the JS API. Until our users start complaining about the 
>>> API not beeing extensible. What you would expect  when using an OO language 
>>> like Java. 
>>>
>>
>> Well, but tell me, do you write a second Java API, with real java classes 
>> that wrapp the Js objects ? and if so, do you use your previous 1:1 Java 
>> API for writing the this second more-java-confortable API?  (I sould do 
>> that) and if so, do you use some Java code generator tool for artificial 
>> create the second Java API form the first 1:1 - overlays Java API ? can 
>> this be mechanized at all? 
>>
>> I'm questioning my self these kind of things for my project YUIGWT. YUI 
>> has a very big API, and unlike other libraries it contains utils for doing 
>> a more structured - object oriented javascript like classes, inheritance, 
>> plugins, attributes, events, etc. All artificially and fully extensible 
>> from javascript. The big desicion I have to make is this: "the objective 
>> of YUIGWT is to bring the YUI public concrete utilities to the GWT user, 
>> like a datatable, a button, etc ". But not to support those utilities 
>> enhancing the Javascript language.
>>
>
>
> *We dont use generator for our APIs. We go the insane way to look at each 
> methods in the APIs we try to wrap! This is a lot of work but it gives us 
> the possibility to optimize/enhendce some stuff. And sometime leave some 
> stuff out that dont make sence for a Java Developer. Plus you come to learn 
> the JS library which is not bad (At my day to day work i dont use GWT but 
>  EXTJS. So Wrapping ExtJS helped me understand  that library better, and 
> hate it even more loooool). *
> * *
> * Concerning building the objects. Like i said before we basically have a 
> real Java Object wrapping a JSO. And we are just delegating to the native 
> JSO. You can have a look at our Java API for Sencha Touch (
> http://emitrom.com/touch4j) to see it in action.*
> * *
> * If you have any question feel free to ping me.*
>
>  
>
>>
>>
>>> .... code....
>>>
>>> That looks pretty cool. Now what if i want to extend Button  and 
>>> override some methods ?
>>>
>>>
>>>
>>
>> This is the perfect example, thank you!
>>
>> Currently in my YUIGWT project (very new project) I do not contemplate 
>> that. What I'm thinking can be a perfect solution for me is : to create a 
>> second Button class, that wraps all current Button methods, as you 
>> suggested in your first post. The user could override some methods, and it 
>> is his responsability to call super.(). In the constructor, they must pass 
>> me the Y object that is responsible for instantiate the "real - native" 
>> Button . 
>>  
>> Well, a pleasure to read you, if you have any other suggestions or tips 
>> about this subject are most welcome. 
>>
>>  -- 
>> 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/-/a-U28tdEaPAJ.
>>
>> To post to this group, send email to 
>> google-we...@googlegroups.com<javascript:>
>> .
>> To unsubscribe from this group, send email to 
>> google-web-toolkit+unsubscr...@googlegroups.com <javascript:>.
>> For more options, visit this group at 
>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>
>
>

-- 
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/-/pAMwpwmGowMJ.
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.

Reply via email to