(⬑Table of Contents)

Version Two

If (and that's a big "if") s2 version 2 ever becomes a real thing, this is an overview of what would most likely differ...

Replace Objects with Hashtables

Objects would be implemented in terms of hashtables. That is, s2 would still have its base Object type but would use, C-side, cwal_hash as the implementation and would store script-side properties in the hashtable, possibly reserving the object-side storage for internal/"hidden" properties. When s2 was first created, hashes were too memory-hungry to justify that, but that cost has, in the aggregate, been cut considerably via memory recycling improvements made since then.

One notable hiccup here is higher-level types which derive from Object, e.g. Array and Native. Their C-level base type is Object and that cannot be changed without significant downstream fallout, so we'd likely need to create "v2" variants of those types in cwal, or even create cwal v2 at the same time, porting those classes to derive from hashes in the process (perhaps even completely replacing the base object type with the hashtable type and providing a compile-time option to switch the internal property storage).

Alternately, and probably much simpler, we eliminate the cwal_hash type and move its implementation into the cwal_object core.

Eliminate Type-lax Comparison Ops

Consolidate type-lax and type-strict comparisons into a single type-strict comparison. i.e. the === operator would disappear and == would behave as === currently does (type-strictly). The different comparison types are conceptually an interesting idea but in practice type-strict comparisons are almost always (95%+) used.

"Compile" Token Chains

The evaluation engine would probably remain more or less the same but would use "pre-compiled" (or "pre-parsed") chains of tokens, rather than parsing its text on demand. This would cost much more memory but would also be far faster for code called more than once.

We have much of the internals for this already, but porting s2's current eval engine to use it would require a significant effort. The "holy grail" would be an API which allows us to use the conventional (slow but memory light) approach or the "compiled" approach, and even mix the two (e.g. compiled for function bodies and loops and conventional for most of everything else), but such an API has eluded me so far, at least in part because the eval engine takes some embarrassingly low-level liberties with the tokenizer engine which are not legal with the pre-parsed tokens.