Status of the DWS JavaScript CodeGen

Here is a quick summary of the current status for the DWScript JavaScript CodeGen, aka OP4JS.

JavaScript CodeGen for DWScript: what works, what doesn’t

Pretty much everything is working, including class methods (virtual or not), var & lazy parameters, records, arrays (dynamic and static), functions/method pointers/delegates, interfaces, operator overloading, etc. in short, the list of “what works” would amount to listing almost every DWS language feature, so I’ll just list what isn’t supported instead, or supported with quirks.

Of course, take this list with a grain of salt, it may be obsolete in the near future 😉

Destructors: JavaScript doesn’t exactly have the concept, you can just “delete” and null fields. Though DWS being garbage-collected, destructors are in DWS more for compatibility with Delphi and special tasks, and you can often go on just fine without them. In practice the limitation is that in a Delphi-side execution, when an object is GC’ed, it’s destructor code will be executed, while on the JS-side, a destructor will only get executed if manually invoked.

DateTime: Date/Time functions are currently not supported JS-side. Though contrarily to the rest of the RTL functions, these will involve a rather heavy framework, as JavaScript built-in features for manipulating or converting date & time are rather lacking.

Variants: they are supported only in limited cases, mostly revolving around passing them around, f.i. as parameters. The reason they aren’t in lies with figuring out what should happen when you do cross-type operations and comparisons (f.i. when comparing a string to a variant, a variant to a string, etc.). The JS resolutions for those are different than Delphi’s, and to be honest, I’m not really sure what the Delphi rules are in all the cross-type cases in the first place. Another option being considered is to not worry about Delphi-side behaviors, and just use the JS behaviors.

StackTrace: Exception’s StackTrace member isn’t supported yet. At the moment stack traces in JS involve browser-specific code, so this may require a significant framework.

ExceptObject: this is a special entity that in Delphi allows to access the current exception, there is AFAIK no direct equivalent in JS, and emulating it would involve a significant amount of extra JS code. Since its usage scenarios are infrequent, it is currently of low priority.

8 thoughts on “Status of the DWS JavaScript CodeGen

  1. You can look at the Variants.pas to see the Delphi rules for variants operations. Afaik first the non variant value is converted to a variant and then the operation is executed. Its basically the _Var… routines.

  2. @Stefan Glienke
    Thanks. There are appear to be quite a few cases and things to deal with, so that would mean a significant bit of JS, and I’m uncertain how many of them really make sense, I mean, in “real” code, it’s usually bad practice to just mix types on operands apart from some special cases.

  3. I’d suggest don’t worry about those rules. Most of then (the more frequent used cases) should be fine anyway.

    I wouldn’t bother emulating this stuff.

  4. @Eric: I am close to completing a reference implementation for a DWScript IDE with the following design goals met:
    1. Should be able to ‘connect’ to a fixed instance of a DWScript at will.
    2. The usual IDE features of breakpoints, single step, call stack, watches.
    3. The ide is a simple form with splitter-base panes but each pane is a frame making it easy to improve the ide layout, eg with drag/dock.
    4. Based on Delphi-functionality with a main project (stores *MainModule*) and from zero to unlimited units and/or include files. A common *.sproj’ XML file stores references to these files and ‘desktop’ settings such as breakpoints. Opening the ‘sproj’ file opens all files and loads the breakpoints.
    5. No components to install.
    6. Only the SynEdit library is needed.

    If you can spare the time I would like to let you see the code & demo. My goal is that perhaps it could go alongside your DWSwcript code publicly so that others might enhance it further? What do you thinK?
    Brian Frost.

  5. @Paul
    Yes Paul, in the simplest case you keep a TDWScript in your app and just open the IDE form (eg on a button click) to inspect / edit it.

  6. @Brian Frost
    That’s very nice, by all means, it would be a worthy addition!
    I wouldn’t have enough times to support both the compiler and an IDE, but yes, I can help with suggestions, reviews, and other might be able to work on it, if only through bug reporting and other things!

Comments are closed.