Wouldn't this cause a problem when you want more than one JSO to implement
Iterable? I wouldn't make the class itself implement Iterable, I'd add a
helper method to return an Iterable, e.g.
public class JsArray<T> extends JavaScriptObject {
public Iterable<T> iterable() { ... }
}
for(T foo : someJsArray.iterable()) {
}
The risk of adding it to the class type itself is that you potentially block
anyone else from making a JSO that implements Iterable.
-Ray
On Tue, Mar 31, 2009 at 1:24 PM, Freeland Abbott <[email protected]> wrote:
> Also, is there a reason (perhaps costs from autoboxing) not to also make
> our JsArrays Iterable?
>
>
> On Tue, Mar 31, 2009 at 10:55 PM, Freeland Abbott <[email protected]>wrote:
>
>> Okay. I'll look into sort and toSource tomorrow; right now I'm away from
>> that project code to see whether I want to try to fight for sort.
>> So this patch should, I hope, be just the easy stuff. Usually when I say
>> something rash like that it turns out I'm very wrong, but we'll see.
>>
>> Regarding JSO, I pulled toSource, but left the I-think-helpful toString().
>> I know Scott worried about "pulling in" other types' toString(), but in
>> separate private email I think his worry is unfounded---best I know, we
>> don't analyze JSNI bodies, so while this implementation references
>> toString() if available, it can't change code size by pulling anything in
>> that wasn't already coming for the ride. I think; I'm sure he or someone
>> will correct me if I'm wrong on that!
>>
>>
>>
>> On Tue, Mar 31, 2009 at 5:44 AM, Kelly Norton <[email protected]> wrote:
>>
>>> Few things:
>>> Overall, I'd like to be more conservative landing things in
>>> JavaScriptObject for a couple of reasons: (1) It's hard to take a mulligan
>>> with these because of their constraints (2) there is always a trivial work
>>> around to create application specific subclasses (with toll free casting).
>>>
>>> >> From r5082: I don't think toSource is appropriate for
>>> JavaScriptObject. It only works on mozilla browsers.
>>> >> JsArray.push: As I recall, this[this.length] = value is faster than
>>> this.push(value) on all browsers. It's not a complexity change like
>>> array.pop() is, but it can be significant. (How I do wish we had continuous
>>> perf testing).
>>>
>>> >> javadoc: The javadoc for these should be written to describe what the
>>> function does. "Direct mapping to underlying sort" is a good implementation
>>> note, but we should actually way what it does and not rely on developers
>>> having an understanding of the JavaScript equivalent.
>>>
>>> >> sort(JavaScriptObject): I'd like to avoid this one if we can. It just
>>> opens up larger questions about the right way to do this. We don't currently
>>> have a convention for representing JavaScript functions in Java. Someone
>>> should probably have a good story there before we add something like this to
>>> JavaScriptObject.
>>>
>>> /kel
>>>
>>> On Fri, Mar 27, 2009 at 2:15 PM, Freeland Abbott <[email protected]>wrote:
>>>
>>>> I think the argument is more for "unnecessary" rather than "bad"...
>>>> although without JsArrayBase (we can make it package-protected, and call it
>>>> JsArrayImpl if anyone cares), we duplicate the JSNI implementation for a
>>>> couple trivial methods. I thought refactoring them into one place was
>>>> nice,
>>>> but trivial enough that I'm not fighting over it. Revised patch attached;
>>>> I
>>>> can go either way on this.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Mar 27, 2009 at 2:06 PM, Scott Blum <[email protected]> wrote:
>>>>
>>>>> I'm going to punt this review to Bruce & Kelly, 'cause I have no idea
>>>>> why having JsArrayBase would be bad. :)
>>>>>
>>>>> On Fri, Mar 27, 2009 at 1:28 PM, Freeland Abbott <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Scott, we already talked about this, but here's the patch for public
>>>>>> review.
>>>>>>
>>>>>> The basic goal is to surface the native length, sort, push, and shift
>>>>>> operators for JsArrays... I know you mentioned that IE6's push may be
>>>>>> slower
>>>>>> than indexed extension, and thus a candidate for deferred binding, but I
>>>>>> wanted to get a basic implementation in first.
>>>>>>
>>>>>> There should be only checkstyle changes from what we discussed (though
>>>>>> that obviously doesn't help the rest GWTC). I also added some checkstyle
>>>>>> fixes to JavaScriptObject, introduced by my c5082.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> If you received this communication by mistake, you are entitled to one
>>> free ice cream cone on me. Simply print out this email including all
>>> relevant SMTP headers and present them at my desk to claim your creamy
>>> treat. We'll have a laugh at my emailing incompetence, and play a game of
>>> ping pong. (offer may not be valid in all States).
>>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
