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 😉
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.
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.
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.
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.
@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?
Whoa… very interested in your IDE. Is it stand alone or (hopefully) be able to be included in a Delphi app to enable scripting?
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.
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!
Thanks Eric. When I consider it at a suitable stage, where and how would I upload?
Comments are closed.