Ping. (This is supposed to be just the non-contentious stuff.)
On Tue, Mar 31, 2009 at 9:55 PM, Freeland Abbott 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,
On Tue, Mar 31, 2009 at 6:42 PM, Freeland Abbott wrote:
> The for (T x: array) ... use case is precisely what's motivating me, yes; I
> don't have any intention of e.g. implementing Iterator.remove(). We allow
> that syntax on "real" Java arrays, but not on JsArrays.
>
> Does returning T[] actua
So the correct solution would be return T[] only for the object array type,
and return the correct primitive array for each primitive array type?
On Tue, Mar 31, 2009 at 6:52 PM, Ray Cromwell wrote:
>
> Yes, My concern is, if you don't make a method that returns a T[], and
> instead make a JSO
Yes, My concern is, if you don't make a method that returns a T[], and
instead make a JSO that implements Iterable, you can only do this once.
Java treats T[] differently than Iterable with regard to the for-each
loop. As usual in Java, the primitive types are treated non-orthogonally.
-Ray
On
On Tue, Mar 31, 2009 at 3:42 PM, Freeland Abbott wrote:
> I'm not sure I understand Ray's concern... JSO wouldn't implement iterable,
> so another subclass of JSO would do whatever the author made it do. Most of
> the methods on JsArray and e.g. JsArrayString[1] are final, but we
> wouldn't have
The for (T x: array) ... use case is precisely what's motivating me, yes; I
don't have any intention of e.g. implementing Iterator.remove(). We allow
that syntax on "real" Java arrays, but not on JsArrays.
Does returning T[] actually avoid creating an Iterator object, or does it
just create an It
On 31 mar, 22:29, Ray Cromwell wrote:
> 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 extends JavaScriptObject {
>
> publ
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 extends JavaScriptObject {
public Iterable iterable() { ... }
}
for(T foo : someJsA
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 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.
On Tue, Mar 31, 2009 at 9:56 AM, John Tamplin wrote:
> My point is I don't see why this is different than any other toString() --
> should we be short circuiting HashMap.toString()/etc for production
> compiles? If an app is concerned about pulling in all the toString methods,
> they will alread
On Tue, Mar 31, 2009 at 9:40 AM, Scott Blum wrote:
> Actually, I didn't mean that it was going to pull in arbitrary amounts of
> code. I just literally meant that the body of that toString() is pretty big
> for a micro-app, like a small gadget based on GQuery. I just don't see the
> value of ad
Actually, I didn't mean that it was going to pull in arbitrary amounts of
code. I just literally meant that the body of that toString() is pretty big
for a micro-app, like a small gadget based on GQuery. I just don't see the
value of adding that code into a web mode production build.
On Tue, Mar
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,
On Mon, Mar 30, 2009 at 11:44 AM, Kelly Norton wrote:
> Few things:
>
> >> 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
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).
>
Kelly, since you have experience with this, I'd like you to be the decider
(i.e. Freeland is now waiting on your LGTM).
On Fri, Mar 27, 2009 at 2:16 PM, Freeland Abbott wrote:
> I think the argument is more for "unnecessary" rather than "bad"...
>> although without JsArrayBase (we can make it pa
>
> 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 n
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 wrote:
> Scott, we already talked about this, but here's the patch for public
> review.
>
> The basic goal is to surface the native lengt
FWIW, in another little project I used a pattern for this that avoids
implementation inheritance that I call self-delegation.
Here's an example:
/** Not put API, but it includes the impl for al getters and setters for all
types. **/
final class JsArray extends JavaScriptObject {
...
public int g
Let's not add this extra type JsArrayBase into the hierarchy. Why can't we
just push the various methods down? We can always factor upward in the
future. If we need shared implementation, we can factor that out into a
package-private JsArrayImpl class.
On Fri, Mar 27, 2009 at 1:28 PM, Freeland Abb
20 matches
Mail list logo
