Re: RE: SIDE NOTE: CIL Schema

Brian,

I had not intended to use the Java libraries. I just wanted
powerful object orientation and most of the features of a
compiled language (primarily type checking). I've come to
appreciate Javascript, particularly with the immediacy of the
browser DOM.

// >I have flags to turn off type-checking and method wrapping
at
// >runtime, once I am convinced the code is well tested (but
// >then may loose stack traces and some error handling).
// 
// Safety and convenience tend not to be important in a
// target platform. Those concerns are pushed up to the
// source language.

Precisely. However, because there is no compile time type
checking, I'm left with artifacts of this wrapping at runtime.
While I no longer perform the argument and return value checking
and the push and pop methods from a stack, I've still got twice
as much text in a class. Sure, I could do string manipulation
but that really hinders the development cycle (might as well
perform XSLT).

MyClass.methodWrap("doSomething", [String, Number,
AnotherClass], Boolean, function (name, age, food) {});

vs.

MyClass.prototype.doSomething = function(name, age, food) {};

I think you asked why go from o:xml->MLML->bytecode
rather than o:xml->Java->javac->bytecode. The fringe languages
in the equation are not as interesting as the intermediary.
The first is just the presentation in the editor and the last
is to be consumed by the target platform. The MLML is the orgy
of various tools and presentations.

Suppose Martin completed o:xml->MLML->bytecode and I wrote
MLML->Javascript. Then magically we have o:xml->Javascript.
It would be much easier to convert MLML to documentation.
I could translate MLML to efficient runtime Javascript,
the wrapped framework, or wrapped for a profiler. Converting
my hack to more efficient code or to be profiled would
be somewhat more difficult. I'd also be unlikely to do it
if I didn't think I could reuse it. Knowing there are a few
other languages that translate to and from MLML gives one
a little more incentive (and the positive feedback grows).

I created these elaborate State Machines and try to keep
the visio (and generated PNG/JPG images) and code in sync.
I think its silly that I can't generate skeleton code from
those images and vise versa. However, there are plenty of
tools for other languages.

Another reason for XML translation to Javascript is to
support various browsers, platforms, and versions. There
are a number of core classes containing if(IE)elseif(Moz).
Such things should be compiler macros or, in the case of
javascript, server side translations.

Alex

=====
Alexander E Genaud <[email protected]>

PGP:     CCC7 D19D D107 F079 2F3D
         BF97 8443 DB5A 6DB8 9CE1
6DB89CE1 http://tinyurl.com/5mdmw


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250