Hi all,

This isn't really a problem, I'm just curious to see if anyone else
has had the same experience as me, and possibly get a little advice
from the Masters...

I like using JavaScriptObject extensions instead of Collections...
About a year ago I noticed that over half of my small projects were
filled with AbstractHashMap$UnmodifiableEntrySet$Volatile... blah blah
blah;  The Collections implementation is awesomely powerful and great
for debugging, but sometimes, all a person needs is a quick, clean
push/pop interface to get/set data {read: production code}.

So, I went through the trouble of making a bunch of JSNI Overlay types
for different kinds of data, and different ways of manipulating said
data.  Of course, I found myself calling .cast() between my Stacks,
Queues and Registers Waaaay too often, and even if dynamicCast() on
JSOs always succeeds instantly, it's still needless method calls and
bigger file sizes.  Soooo, I scrapped the multiple-JSO types in favor
of two monolithic JSNI objects, one for primitives, and the other for
generics.  I defined all the basic data operations, like PushInt,
PopString, SetBoolean, GetCast<?> and so forth.  I checked my compiled
output, and GWT does it's magic, and only includes the static {and
inlined} functions I accessed in a particular use-case.  {I even went
so far as to compile out WidgetCollection, but that's another story}.

This method uses String-namespacing, integer counters and basic data
manipulation algorithms to store / retrieve data in a JSON-ic manner
that is consistent across iframes so I could do some XS-communication
without resorting to calling on my server {or trying to normalize
field names across different compiles}.  In simple cases, it's much
faster than a List or Set {but I can't do any Map-like functions
without becoming much slower, mainly due to dependencies of .hashCode
() on Strings}.

Examples:
{N:3,N0:33,N1:1.0,N2:-51}
{W:2,W0:[...@com.google...widget$1],W1:[...@com.google...widget$4]}

Of course, I'd usually combine these into a single object, since
numbers get a different namespace prefix than objects, and collisions
can't occur, but you get the idea... No [].push(), No nasty .length to
ruin for(x in y) and No ConcurrentModificationExceptions {which are
actually really good for debugging, unless you've got a really good
grip on exactly what your app is doing}


What I REALLLLLLY want to do is to take all of the functions in those
Overlay types, put them into a .cache.js file, auto-insert that faster-
than-304 script into all my independent modules, and then let all my
Java methods use the JSNI functions without recompiling the same basic
tasks into every file.  Maybe, with some kind of Annotation for "Do
not compile", possibly taking a string argument for each method to
create my own namespace {kind of like the StyleInjector in the
Incubator}?  Should I just write my own external Javascript and
overlay it manually{kind of icky, as it would be very wasteful and I
can't dynamically modify the {"namespacedIDS":0} to avoid clashing
with other javascript I might include}?  Is there some kind of
Generator or Linker methods I can use to do this with existing
technology?

I read somewhere about a new script-splitting technique for 2.0 that
will let me put everything into a single monolithic project, and just
download it in multiple pieces {maybe one per onModuleLoad, eh?}  The
very idea of this makes me wet, but I've no idea where to start, or
even if I'm on the right track.  Maybe Collections will get optimized
to the point my overlay types get blown out of the water, but for
right now, I just want to externalize my JS data manipulation
algortihms, yet keep it all in Java...  I don't like redundancy, but I
can't stand seeing a file over 200k, so I keep splitting my modules
and using iframe hacks to get it all communicating semi-
synchronously.  My biggest problem now is that I'm deploying to
appengine, and it's got a 1000 file limit that I blew past a while
ago, so I've had to split into two projects, on two domains {one to
test and build the core, and the other that uses a jar of the core to
get my file count back below 1000}.  Rejarring builds is a pain, but
appengine is sooo worth it.

Also, I've noticed that native code on Overlay types usually gets
inlined, whilst regular public final methods usually get turned into
static functions.  Is this even close to right? Where's the best place
to draw the line for inlining?  ...I used to use JSNI for everything,
no matter how many times I had to write x...@com.package.jsni::PushInt(I)
(0) or whatever, but that led to massive bloat... Is there some tricks
or guides to getting really fast JSNI methods? As it stands, I usually
make two versions of every method, one that checks the value before it
returns it, and another that doesn't.  This way, when I'm looping
through data, I only safe-get a data type once, then fast-get it for
the rest of the iterations.  Example:


static final String NUMBER_PREFIX = "N";

public final double getNum(String ns){
return hasAndIsNum(ns)?Num(ns):SetAndRetNum(ns,0);
}
public final native double Num(String ns)
/*-{ return this[ns]; }-*/;

public final native double SetAndRetNum(String ns,double val)
/*-{ return (this[ns]=val); }-*/;

public final void loop(Task<Integer> todo){
if(getNum(NUMBER_PREFIX)==0)return;
for(
    int i=-1;
    ++i<Num(NUMBER_PREFIX);
     todo.use(Num(NUMBER_PREFIX+i)
);
}

Anyway, I rant on.  My main question: Am I being foolish trying to
trim out all the jre emulation for a little speed bonus now?  Because,
if I run a benchmark in 2.0 and discover that List is suddenly four
times faster, I'm going to feel like I wasted a lot of time on this.
I'd post a link to the actual source code for these files, but I'm
pretty sure that's called a shameless plug, and is frowned upon
here...  Besides, my actual naming conventions are TERRIBLE and I'll
get laughed at.

If you actually read this message, I thank thee for thine time;
And if you have some advice for me, I'd love to hear it.

In Truth,With Love
-X
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
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