Some cleanups to Frog to avoid looking up its builtin types too much

Small performance improvement: avoid looking up builtin types too much by tracking them, particularly ones in coreimpl like NumImplementation.

I also did a few refactorings:
* Tried to tame the "nativeName" stuff to keep the code paths from forking too much
* Removed the bad code duplication between needsConversion and convertTo  in Value (they had gone out of sync again!)
* Simplified the function wrapping code & made it clear it's about isolates. The code still checks for DOM, but conceptually it's part of our isolate impl. If we had a different way to tag native function types (e.g. perhaps the "native" keyword, if it's allowed in that position?) we could remove the DOM check there.

Committed: https://code.google.com/p/dart/source/detail?r=3057

[Jennifer Messerly, 2012-01-06 21:36:29]

tbr

http://codereview.chromium.org/9110027/diff/2001/utils/apidoc/html_diff.dart
File utils/apidoc/html_diff.dart (right):

http://codereview.chromium.org/9110027/diff/2001/utils/apidoc/html_diff.dart#...
utils/apidoc/html_diff.dart:39: for (var type in diff.dom.types.getValues()) {
I was trying to get rid of "world.dom" completely. Ended up not being able to
kill it just yet, but it's still good IMHO good to avoid depending on that
field.

http://codereview.chromium.org/9110027/diff/4004/frog/member.dart
File frog/member.dart (right):

http://codereview.chromium.org/9110027/diff/4004/frog/member.dart#newcode1074
frog/member.dart:1074: // TODO(jmesserly): using the "node" here feels really
hacky
one cleanup I'd like to do:

if we're in visitNewExpression and we get back the constructor, don't just call
"invoke" on the MethodMember. Instead call invokeConstructor (which should be
called "construct") directly, and add a parameter to it saying whether its a
"const" or "new". 

Most of the reasons that "node" gets passed around instead of "span" is because
of this problem.

[jimhug, 2012-01-11 19:09:53]

LGTM!

Nice cleanups.  My only question is about the TODOs that you added "we shouldn't
be special casing DOM anymore".  I agree that that is a nice ideal to shoot for;
however, it would not trouble me a bit if we still had some special case support
in the compiler for DOM by the time of a 1.0 ship - given that dart is a web dev
language after all.

http://codereview.chromium.org/9110027/diff/4004/frog/member.dart
File frog/member.dart (right):

http://codereview.chromium.org/9110027/diff/4004/frog/member.dart#newcode1074
frog/member.dart:1074: // TODO(jmesserly): using the "node" here feels really
hacky
Yes!
On 2012/01/06 21:36:29, John Messerly wrote:
> one cleanup I'd like to do:
> 
> if we're in visitNewExpression and we get back the constructor, don't just
call
> "invoke" on the MethodMember. Instead call invokeConstructor (which should be
> called "construct") directly, and add a parameter to it saying whether its a
> "const" or "new". 
> 
> Most of the reasons that "node" gets passed around instead of "span" is
because
> of this problem.

[Jennifer Messerly, 2012-01-11 19:22:11]

On 2012/01/11 19:09:53, jimhug wrote:
> LGTM!
> 
> Nice cleanups.  My only question is about the TODOs that you added "we
shouldn't
> be special casing DOM anymore".  I agree that that is a nice ideal to shoot
for;
> however, it would not trouble me a bit if we still had some special case
support
> in the compiler for DOM by the time of a 1.0 ship - given that dart is a web
dev
> language after all.

Totally agree :). I'd be nice if the DOM differences are captured in the
metadata somehow, i.e. like what we did for "hidden prototypes", rather than
making behavior different if the lib happens to be called "dart:dom".
(especially since node.js often has the same issues). But I agree we might not
get there, and I wouldn't feel too bad if we still have library == "dart:dom"
checks.

> 
> http://codereview.chromium.org/9110027/diff/4004/frog/member.dart
> File frog/member.dart (right):
> 
> http://codereview.chromium.org/9110027/diff/4004/frog/member.dart#newcode1074
> frog/member.dart:1074: // TODO(jmesserly): using the "node" here feels really
> hacky
> Yes!
> On 2012/01/06 21:36:29, John Messerly wrote:
> > one cleanup I'd like to do:
> > 
> > if we're in visitNewExpression and we get back the constructor, don't just
> call
> > "invoke" on the MethodMember. Instead call invokeConstructor (which should
be
> > called "construct") directly, and add a parameter to it saying whether its a
> > "const" or "new". 
> > 
> > Most of the reasons that "node" gets passed around instead of "span" is
> because
> > of this problem.