Re: RE: XML] Re: SIDE NOTE: CIL Schema

Martin and Brian,

I'm happy to see others speculating on what I have done.
Unfortunately, I have not created a research project, but
a very practical solution to an ugly problem. I have not
actually taken Java and converted it to Javascript, I only
wish I were able to do that, and see incredible benefits to
such a system. I have created Javascript functions that
emulate a subset of object oriented sugar found in languages
such as Java or C#. I do not expect any Joe Java programmer
to convert Java to Javascript, nor do I expect an average
Joe Javascript programmer to understand the output. While
I've tried to wrap the paradigm with a number of utilities,
a solid understanding of the differences between Java OOP
and Javascript prototypes is suggested.

The most obvious limitation to my solution is that the
type-checking occurs at runtime, rather than compile time.
The wrapping functions increase the complexity. 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).

I would be happy to write an MLML -> Javascript translation, or
more likely, MLML -> (modified Javascript + utility functions).

Note, that it is my prediction that Microsoft will be
implementing the latest version of ECMAScript (with
type-checking and OOP) in the next version of IE. I also
predict that it will (A) be CLI/.Net and thus (B) any
.Net language will run on the client, manipulate the
DOM, etc, and will render this conversation irrelevant.

None the less, it seems like an interesting project. So,
what have I done?

I have a number of classes: Core.js, CallStackLog.js,
and others that will need to be imported into an HTML
file for any of this to work. I can't publish those --
but I hope MLML -> JS will make most of them irrelevant.
I've also learned enough in practice that a future
rewrite would be much better and little resemble its
predecessor. Here is an example class snippet today:

function HttpConnection(requestBroker)
{
  this.priv_requestBroker = requestBroker;
  this.init();
}

HttpConnection.classDefinition("HttpConnection", Stream, []);

HttpConnection.classProperty("standardProtocol", function()
{
  // etc etc etc
  return "chrome://";
});

HttpConnection.methodWrap("httpPost", [RequestTicket, String],
                          Boolean, function(ticket, url)
{
  return this.priv_httpOpenMethod(true, ticket, url);
});


the methods Function.classDefinition(), Function.methodWrap(),
and
Function.classProperty() provide most of what one would expect
from an OOP language. ClassDefinition defines the class name,
and
its parent (extends), as well as an array of interfaces (in
the above case, none). MethodWrap defined a public method with
an
array of argument types and the return type. Private methods are
defined in the constructor, there is no package concept
(although
possible). ClassProperty defines a static field, class method,
or
member method with no wrapping.

Unfortunately, we'll be going into production/deployment
shortly,
so the MLML translations will go on the back burner and will not
get the benefit of massive testing. So, I've just been trolling
on this mailing list.

Alex

PS - Martin, I'm on the mailing list -- no need to CC me.

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

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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com