[Laszlo-dev] pre-RFC: target-specific code

[Asger Alstrup]

[Proposal for how access Flash specific APIs]

Having access to the raw Flash API is really a must-have to create the best 
applications possible, so this proposal is very much welcomed. We are 
already reliying on the #pragma hack, so an "official" way to do this would 
be great - especially since the #pragma hack is fragile: if it is not 
followed by some dead code, it seems that instructions might be "optimised" 
away. The proposal itself looks fine as long as it is open-ended and allows 
access to the full underlying API.

However, I'd like to ask for even more (or some else): The ability to 
include inline flash assembly. The performance of the Flash engine is so 
poor that the loss in performance due to translation from JavaScript to the 
flash bytecodes is costing too much: Especially the difficult choice of 
whether to put a variable in a register or use the top stack element as 
"register" costs a great deal of performance. For maximum performance, you 
really need to decide this yourself, so flash assembly is the way to go.

So some mechanism to include assembly would very much be welcomed, whether 
it is based on flasm, or in the worst case, maybe even just hex-codes. 
(Neoswiff supports inline assembly, and flasm allows ActionScript to 
contain assembly as well.)

Another thing is documenting the ABI so that interoperability with other 
Flash technologies becomes possible. There are lots of different Flash 
technologies these days: Flex, Neoswiff, Xamlon, Mtasc, haXe, flasm, and so 
on. And for each of these, there are lots of libraries: actionstep, flex 
components, and what not. If it was technically possible to mix & match 
different technologies, that would really open the door for making nice 
stuff quickly. This shouldn't be technically hard, since the Flash canvas & 
runtime is the common building block, but it does require the ABI to be 
documented to allow bridging conventions: The ability to access variables 
and functions, and interact with the "GUI" loop.

Laszlo is great for dynamic user interfaces that are quickly put together, 
and to some extend XML based stuff. However, it is not so great for user 
interfaces with lots and lots of dynamic visual elements or performance 
critical data processing - the overhead is simply bringing things to a 
crawl, making it unworkable for really complex stuff.

The other main problem I see with Laszlo is programming in the large: 
Without static type checking, it is difficult to manage a large project 
with many different programmers. Simple refactoring is difficult, because 
you get no help from the compiler to make sure all instances are caught.

Regards,
Asger Ottar Alstrup