P T Withington wrote:
This source:
var s = new Sound(t);
Compiles to this:
var v1 = Sound.make(t);
Since Sound is a built-in object, it doesn't have a make() method.
So, in LzRuntime.lzs, you will see that I define .make for all the
Javascript native objects. You probably should do the same thing in the
swf kernel for all the Flash native objects.
I'm not sure this is necessary for Flash, but it's important to know for
LFC hackers...
Or, if you just need to get at one of them, you can say:
#pragma "passThrough=true"
right before your new.
This works like a charm!
It seems like the compiler is going overboard assuming every 'new
foo()' means make a new Laszlo class called 'foo'. Let me know what
you find!
It's true. The compiler makes no effort to distinguish our classes from
runtime classes. So the runtime classes must be bent to our way.
I am concerned about us going through and bashing runtime objects to add
a make method... Then again, I suppose the only other option is to have
'new foo(...)' compile to 'foo.makeClass(...)' and have makeClass
determine if it's an LFC class or not - adding lots of runtime overhead
for each new.
Your decompiler is mistaken about the extent of the `with`, however.
The `with` block extends around the entire expression. This is
intentional, and is to make up for a player bug, where top-level
functions get defined with no context, rather than in their correct
lexical context. It costs nearly nothing to do this and it makes it so
any function can be invoked from an idle task without the programmer
having to make explicit all their global references. This is not new to
Legal's -- it's how we've been doing it for a while...
I'm glad the decompiler is mistaken! It seems implicit this is more
important for user/LZX code.
I think we should require the LFC to always use this. so we can drop the
extra overhead - with {} is extremely expensive in IE DHTML...
-Max
