Do you use Integers in a dictionary to link objects created in the script with partner objects created in the xojo program? I once described that method years ago in the forum or in a blog post. That works reliably (keep also track of released objects), but requires a lot of boilerplate code on both sides.
Not that it really says much, but the annotation is: “This case has been closed because it has been decided that this feature will not be implemented.” In fairness I can’t say that other vendors will often go into any sort of detail or justification of such a decision, particularly if it exposes that the design of the feature is in any way hack-y or has built-in limitations and would require significant refactoring or rewriting.
I went in and up-voted several of these old tickets FWIW. I certainly would want the repro’d bugs fixed if I were going to make extensive use of XojoScript without constantly inventing new naughty words. I’m getting too old for that crap.
Oh yeh. Gazillions of them. My 20K+ line prefix is a mess of classes that reflect actual classes in the application, typically via an integer ID supplied by the context. Ugly, but necessary.
Ever thought of writing code that auto-generates those stubs? It could do that inside you app, by introspecting a class that you added there, then generate the script part of it? I wonder if that’s feasible.
Some of my preprocessing is code, that writes code, and that newly generated code writes more code. And that writes yet more code.
Its awesomely hard to follow but works decently and gives me the result I posted on my blog
In part I need to do this because introspection ISNT a core part of the language so it doesnt exist there. Otherwise I’d use that
Is it correct that this code generation chain happens entirely during pre-compile and compile time?
And no dynamic code generation at runtime is involved?
That’s possible, but in my case I do it manually because (a) I want to restrict end users to a subset of the full class API, (b) sometimes those classes refer to other classes that should also be end-user visible, and (c) I need to add special comment features in order to programmatically generate a hierarchical API guide for those pesky end users.
Not that I have many end users that can program… It’s more about the intellectual fun, and also myself using the system to create scripts for the grateful non-programming end users, to get them off my back when they demand a new application feature.
If it’s for the intellectual fun, then here’s at least one more idea: To restrict or otherwise parameterize your internal support classes for the scripts, you can add attributes to them and their members, or simply make some public and others protected if feasible and then detect those with introspection. You can do a lot of nice tricks with introspection, and if you haven’t tried before, it’s worth a try.
By “not a core part of the language” you mean it isn’t true introspection (or as we call it in .NET, reflection) in some sense? Or just that it’s bolted on via some class and isn’t part of the language grammar, which is why it’s not inherently available in XojoScript?
Yes
The core language that Xojo supports is whats in XojoScript
Reflection isnt part of that very core language.
You can define classes methods modules classes etc
yes
Everything else is added via plugins OR the “runtime” - a set of classes & modules that Xojo adds to any built application. There’s a different runtimes for console, web iOS and desktop apps.
Introspection is one of these add on modules + classes in that module
Since these are NOT added to XojoScript in any way things like Introspection do not exist in XojoScript
Same goes for may additions to API 2 - String is a MODULE in the runtime that adds in many new or renamed methods. Integer is similar. There are modules for many things like that.
( note there is a DATA TYPE and a MODULE in the runtime named String - its magic that lets Xojo create modules with names that, for every other user, are actually treated like reserved words - there are Macy ways you can do this too but … )
Again , because they are not “the language itself”, they dont exist in XojoScript
Hm. Sounds alarmingly crufty. Probably high time they hired a compiler engineer to clean all this stuff up. If I were working at Xojo I imagine this low rumbling sound coming from the sub-basement where the technical debt is piling up, slowly becoming sentient …
Yes I agree there are higher priorities such as IIRC some double precision number issues. I would also like to see a native decimal type although there looks to be an okay free C++ plugin for that.