I started building my version of the engine and it's going pretty well! I'm doing it quite differently to the original way.

The main thing is, I'm essentially transpiling the source into plain JavaScript--then using a Function constructor to return the built object that's ready-to-go. In theory this transpiled JS could be cached on-server and served for faster start-up times. (I know they're only a few ms anyway, but ya know...)

My focus is on preparing everything as early as possible so that while running, the bare minimum processing has to happen. So then generating stuff is "blazingly fast" as a wise man once said.

But anyway... this post, I just have some suggestions. There are some things that are noted as TODOs in code comments, which is fair enough. But here are a few more that might be nice to add. @perchance

Again, this is all just spitballing as I think about how I'm going to build my perchance-like engine for funsies. So if you're not on-board with some of these, that's totally chill! You do you!

Suggestions

.selectAllPossible

Currently we have .selectAll which specifically gets all "option" children, ignoring odds. This would be a way of getting just those that could be output.

It should probably also take into account consumed items in .consumableList objects. Like a "get the rest" operation if you like.

.consumableList method overloads

Currently all methods and functions handle consumableLists as well as just regular lists. It could be more maintainable (potentially less fiddly), and better for performance if the regular functions didn't have to worry about any of that stuff.

So, when a consumableList is created, it could have its own special versions of whatever methods are required added to override the regular ones--something like that.

Not much gain for creators, but just an idea that might have some advantages.

array.selectAll return a copy

Currently it returns the array itself--which could then be manipulated and changed in code, and would affect the original array because it is the original array.

.selectAll normally sends out a new array object with all the items put into it, for regular nodes. So, doing the same for arrays would be more consistent there, and keep with creator expectations.

And it's simple code anyway, so should be an easy change to make.

Array text transform methods

When I looked, it seemed not all the text transform methods are added to arrays.

I was thinking, as there's an array someplace with all the text transform methods listed, it could be used to automatically add methods for all of those at once--making sure it's consistent with everything else.

Single/Multi-line functions

Programmatically these are the same thing, just functions (with some fanciness, I know). But (at least for me) I do trip up on them from time to time.

Like, I put code on the same line but later want more to it, or just to split it onto multiple lines, etc. But forget that you can either have code on the first line or on the second line--not both.

I think it could work just by letting all functions be single or multiple lines and leave it at that. As functions can't have child items anyway, I don't think this would cause any problems with how the code is built by the engine.

Fewer bugs/misunderstandings, (most likely) simpler code in the engine to build them.

(I also have aspirations to optionally add { on the first line and a single } on the last line of code--making it way easier to parse and just grab all the contained code. But that's a whole other thing... 😜)