Announcing ObjoScript

I knew I’d seen it
https://tracker.xojo.com/xojoinc/xojo/-/issues/15477
cant say I even know why it was closed

I’ve submitted a few requests over the years for XojoScript
https://tracker.xojo.com/xojoinc/xojo/-/issues/?search=script&sort=created_date&state=opened&author_username=normanpalardy&first_page_size=100

I’ve reopened (or requested reopening?) that issue.

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.

1 Like

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.

1 Like

Thanks for that. I’ve added some comments and "thumbs up"s to several of them (for all the good it will do).

more or less thats what I do

1 Like

Sure - I worked there then
And I still couldn’t tell you why that decision was reached
I dont recall any discussions about it

XojoScript being the “core” language without any adornments like the framework means they need a compiler engineer of some kind to do much to it

So I dont hold a lot of hope for them either
Sadly

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.

(Huh, getting a bit off-track here, sorry)

to some extent it is

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 :slight_smile:

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. :crazy_face:

Yes
I cant generate code for XojoScript while running a script
Same as in Xojo where you cant write code for the compiled app while its running

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 …

1 Like

there are compiler issues where a compiler engineer would be needed

many in the community have said that since the previous one left in 2017

moving introspection into a core language feature probably isnt high on that list

2 Likes

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.