UInv VS ecma262

If you look in the UInv GitHub page, I uploaded a v0.9.7.3 bugfix release there which fixes that and a few other things. I just haven't put it into its own release package yet, though I probably should have.

Also, I should note that there's a bug in the v0.9.7.2 version of the BagHasAllItems(), BagHasAnyItem(), and GetAllBagPockets() functions, as well as failure to update UInv elements placed outside of a passage. I've just put up a UInv v0.9.7.3 bugfix release here (you can click the "Raw" button there and then save the page to download that code). Use that JavaScript code instead to avoid those bugs (though make sure you don't overwrite your aliases or your bag and item definitions).

For just about anything else, my Universal Inventory System (UInv) should be able to handle it (it's about 97% complete code-wise, though I really need to do a bunch of work on documentation, sample code, and testing).

Actually, I had a system like that in mind when I created my Universal Inventory System (UInv).

Yeah, it's a huge pain in the ass. I was working on building this feature into my Universal Inventory System (UInv) when I got stalled due to life stuff, so I've wrangled with this problem before.

I would look into u/HiEv's Universal Inventory System. Don't be too daunted by the sheer volume of documentation -- it might be overwhelming at first look but if you stick with it you'll be rewarded with an extremely useful inventory system with a very large volume of functions you can use to get, set and manipulate inventories and objects.

Specifically I'm using HiEv's Universal Inventory and use a function to add items to the inventory. This works in the "Start" passage and the item appears in the inventory no problem, but the same function will result in a maxed call stack if I go deeper into the game.

If you're interested, you might want to check out my Universal Inventory System (UInv), which is intended to be used in RPG games and the like. Admittedly, UInv isn't quite up to v1.0 standards yet, especially since the documentation and sample code needs a lot of filling out, however it's already perfectly functional in allowing you to set up and handle all sorts of complex inventories.

I also have an .addArticle() function (click to try it out) for doing that kind of thing included in my Universal Inventory System (UInv). If you want to, you could extract the .addArticle() code from within the UInv code to simplify writing your own macro.

These aren't valid JavaScript (@@iterator would throw an error). They are actually internal Symbols used in JavaScript. They are used to implement features like iteration, instanceOf, and such internally. They actually might get removed or changed

Note that in previous editions, the ECMAScript® Language Specification used the term "lexical environment" before it decided to rename it to "Environment Record" so you might encounter this term in other definitions and tutorials.

For a new specification to be written, you need two things, a_ technical committee_, and a standard. The standard specification for JavaScript is called ECMA-262, and the technical committee is Technical Committee-39(TC39).

4. Proposed something else [ https://github.com/tc39/proposal-ptc-syntax ]

While apple is against Syntactic tail calls, they’re mainly just opposed to versions of it that would remove/unrequire the tail-call optimisation they already do: https://github.com/tc39/ecma262/issues/535

For the version of it that is backwards compatible, they wouldn’t need to do anything other than recognise it as valid syntax. Their main concern is that it "could add confusion with very little benefit."

The spec for STC has a critique of PTC:

- performance

- developer tools

- Error.stack

- cross-realm tail calls

- developer intent

See: https://github.com/tc39/proposal-ptc-syntax#issues-with-ptc

Apple's 2016 response as to why they won't implement STC is here: https://github.com/tc39/ecma262/issues/535

- STC is part of the spec and will take too long to change.

- Now that they've implemented support for PTC, they don't want to regress web pages that rely on it.

- They don't want to discourage vendors from implementing PTC by agreeing to STC.

- They don't want to introduce confusion.

Some of these arguments about confusion and delays seem wrong hindsight, since on every point things would have been better if they'd just agreed to the compromise of STC.

- It would have been part of the spec years ago

- STC would have had a clear way for web pages to know when tail calls could be relied on (and PTC would have been optional)

- Other vendors didn't implement PTC in any case, despite no agreement on STC

- There's even more confusion as things are now