mst

13 days late but for posterity:

Yes. Not Wanting To Do That was the motivating factor for coming up with this approach :D

8 days late but for posterity:

So far I've only ever been using a private symbol that only exists within the codebase in question (and is then exported to other parts of said codebase as required).

If I ever decide to generalise the approach a bit, I'll hopefully remember to do precisely what you describe.

Possibly with the addition of providing an "I am overriding this deliberately" flag that blows up if it doesn't already have said symbol.

But for the moment, the maximally dumbass approach in my original post is DTRT for me so far.

Oh my word.

    const defer = f => ({ [Symbol.dispose]: f })

    using defer(() => cleanup())

That only just occurred to me. To everybody else who finds it completely obvious, "well done" but it seemed worthy of mention nonetheless.

I regularly add Symbol based features to JS libraries I'm using (named methods are riskier, of course)

    import { SomeStreamClass as SomeStreamClass_ } from "some/library"
    export class SomeStreamClass extends SomeStreamClass_ {
      [someSymbol] (...) { ... }
      ...
    }

I have not blown my foot off yet with this approach but, uh, no warranty, express or implied.

It's been working excellently for me so far though.

I feel like it would be creepy if the kid was using it without anybody ever checking up on it ... but I think all of my friends with kids would say that the answer to that is "parenting."

I mean, giving a kid an unlocked iPad and not bothering to do basic supervision can also have really creepy results, so I'm unconvinced that something like your work actually makes anything worse in the negligent parenting situation, and seems like it could be a lot of fun in the competent parenting one.

If you haven't already done this, I'd note that I can think of a number of parents who would probably rather enjoy a version of story mode that let them collaborate with their child and your code to put together a bedtime story before they turn it off for the night and tuck the kid into bed.

OpenAI stuff in general seems (to me, at least) to be overly positive and confident in terms of how it replies.

While I make no foolish claims that it's perfect, I've found Claude feels much less arrogant, and was genuinely appreciative when one of its replies started with an (accurate, of course I checked primary sources to verify that) analysis of the first half of my question, and then for the more obscure second half said "I'm not sure if I can answer that without hallucinating, but here's some stuff you could try researching."

Certainly Claude's tone and "attitude" (FSVO) works much better for me than any other LLM I've tried, though mileage will, of course, vary.

(I have zero connection to the company and am still on a free account, I'm just quietly impressed relative to the competition)

I absolutely agree with your analysis wrt current tech - however, I suspect the person you're replying to is talking about "what would be really cool" in terms of it happening in a future where the relevant underpinnings had advanced to the point where it could actually manage the situational/nuance stuff properly.

I almost certainly wouldn't want to use something that tried to implement it now but it's a lovely dream and the state of the art keeps advancing at quite the speed (i.e. faster than I would have predicted, even when I do my best to take into account that it keeps advancing faster than I would have predicted ;).

It does kinda make sense to me that the various non-US subsidiaries that survived did so at least in part because those places didn't have anything like Walmart.

Whether they'll be able to continue to survive in a world containing the current incarnation of Amazon is a different question and I've honestly no idea how that will turn out.

Once you get as far as FDIC insurance being involved, the bank generally ceases to exist (ideally via a fire sale to another, more stable bank) and the shareholders generally get (all but) wiped out, at best.

Competent risk management so that doesn't (generally) happen is a core competency for a bank, and if regulators think you're doing it wrong they will come down on the bank's leadership like a ton of bricks.

If anybody reading this comment would like to learn more from people who understand the area far better than I do, I would recommend patio11's 'Bits About Money' and Matt Levine's 'Money Stuff.'

I remember some years ago we got somebody joining irc.perl.org #perl to ask for help replacing perl with lua as a game scripting system.

Obviously, a few people were like "uh, why would -we- want to help you with that?"

As soon as I saw an example of this existing code, however, I told said people to STFU ... because for some arsef_cked reason I don't understand at all, they'd used EmbPerl of all things for the scripting, which is basically "PHP for mod_perl" and exactly as horrible as you might imagine even when used for its actual purpose rather than in this case for something completely unrelated.

Even if sensible perl would've been an acceptable approach (and speaking as a veteran perl programmer, I would still consider lua to be more suitable; I strongly consider an importand part of the Zen of Perl to be knowing when to use something else) the approach they had taken was an abomination unto Nuggan and very much deserved to die.

What they had was very definitely the sort of perl code that justifiably contributes to people hating perl, and I considered it a service to perl to help them rip it out in favour of lua code that actually made sense.

(I, personally, think perl works very well as a scripting layer for e.g. irssi, though you might come away disagreeing if you read the average irssi script rather than ones written with a little care and concern ... but for a game? Nah, lua all the frigging way)

If the map editor is an extension (and they have lots of example extensions on github, all of which I've checked are under normal open source licenses) rather than a set of patches to the core code itself, it isn't subject to the Defold License in the first place.

(so if the extension API is missing something, contribute the feature(s) you need back to core, then you can write your extension free of issues, so far as I can tell)

Paid extensions are allowed, which seems like a neat compromise.

If you need to add an extra API or something to the core to make your paid extension work, you can't charge for that, which I think is designed to incentivise "improve the extension API, contribute that back to the core project, then go wild on your commercial extension and see if you can get people to pay for it."

I have no clue whether this approach will turn out to work in the medium-to-long term, but it's a fascinating idea and seems at the very least like an experiment very much worth conducting.