Nah, don't throw the towel already! o) From Jon's perspective, it kinda makes sense now to me, why he is defending the current situation. If you don't used embedded script dialogs, you did not encounter non-language specific DO-modifiers in your button editors text area or in an external script yet.
Any modifiers used so far, were hidden in the button code, the JS or VBS part is cut out and presented to you for editing. You can see that when looking into a the XML of a button:
This is fine I guess, but once these modifies make it into the text / code area or the external script file, things start to get difficult maybe..
Let's take some time and think.. @Jon, I was wondering, how the @include actually worked, as mentioned above, but I thought it was offtopic here. But maybe it is not off topic, because if you could move / wrap the functionality of @include into DOpus.include(), things would be fine and we could keep clear of modifiers in the code.
In theory an include is as simple as this for any WSH language:
The big downside, you need to write WSC files, which are a somewhat painful to handle. So I'm actually curious how you are able to include an external script file and combine that external script context with the local one (from the button editor e.g.). How is that done? If that magic can be used from a different spot - thinking DOpus.include() again - then maybe there is solution on the horizon maybe, just maybe of course! o)
Addition: @include seems to be able to combine an (external) global script context with the local one(?).
Whereas GetObject() from WSH or require() from nodejs, only import a single object into the local context - probably a big difference in handling? But maybe there still is a way to make it work with a DOpus.include() somehow (in the future?). The other guys were thinking in this direction as well it seems.
@cyilmaz, @pro, @MartO thank you for sharing your thoughts and ideas as well. o)
Another completely JS-script compatible syntax would be encapsulating the statement as string, just like:
"use strict"; // <- this has been a standard forever in JS world now
It could be "@import './mydir/myfile.js'"; for example.This wouldn't break any linters. In fact, any future custom DOpus statements could be wrapped like this.
Ok we've added this in 13.6.7. The format is //@@include (two @ symbols are required).
We couldn't find any obvious way in ActiveScripting to perform multiple parse steps of separate bodies of code, so the way we do it is to simply merge the files in memory and parse them altogether. Not very elegant, but it works. But this means of course that solutions like DOpus.include() aren't possible, because the including has to be done before the script is parsed.
I just tried //@@include in 13.6.8 and I'm happy with it. Thank you, @Jon, for listening despite our differences in philosophy!
@cyilmaz I'm not sure I'm going to start down the TypeScript/Transpiling route atm, but it is fascinating and I'd be very interested in your current setup and lessons learned.
@MartO Imagine you can use many (not all, but many) of the newer ES functions as you wish: classes, interfaces, private/public methods, enums, etc., have full, strong type control, excellent IDE support through Visual Studio Code... Most runtime problems are eliminated in design-time already thanks to typing & linter. And when you transpile your project to ES3 with some help, a single file comes out which is DOpus/JScript-compatible, it's a dream! <3 The TS learning curve is not too steep at all, especially if you're fluent in JS and/or strongly-typed languages. Good news is, you can also stay in JScript-land, use plain DOpus JScripts, but use VSC as editor and still enjoy a linter and helpful VSC-features, that is why I'm so invested in this topic.
I can post about VSC/TS updates later; my post history has many pointers.
Thank you, @cyilmaz, you sound really enthusiastic! I have read your older posts on this, which is why I'm so tempted... But it's also why I'm hesitant.
Haven't done much TS yet, but lots of other languages, so that wouldn't be an issue. But setting the whole thing up feels a bit daunting, especially for someone (me) with little knowledge about node.js and all the background mechanics. As I said, still undecided.
