Trollies are usually plastic-coated. If you’re gonna do this please burn it off first with a nice hot fire, then scrub off all the plastic residue before cooking food on it.

If it’s tin- or zinc-plated you run the risk of metal fume fever if you breathe the fumes, but once-off it’s probably not much of a hazard. Unless it’s cadmium plated (peculiar yellowish hue), in which case the fumes and residue are quite hazardous.

It’s also worth bringing a spanner to remove the castors – they’re usually decent quality and can be used for better purposes than a shopping trolley.

Not sure if any of this advice transfers with the programming analogy.

I’ve been trying to basically build a library that helps you put together a distribution archive.
And my initial plan for the API looked something like this:

Distribution::new("my-program")
    .dir("assets")
    .file("favicon.png", |path| build_favicon(path));  // "|path| ..." is a lambda function that gets the target path passed in

So, it would allow you to define the file structure, and for the parts that actually need to be built, you’d provide a lambda function, which it would automatically run or not, depending on whether the inputs changed.

Right, inputs, what are those? I kind of need my user to tell me. So, I decided to implement the caching as a separate API, which you would call on your own when you get called by the lambda function.

Then I realized, I kind of don’t need the lambda function then. I could just construct file paths and then my user calls their build_favicon(...) function or similar on their own.

There is just one crucial problem with that. This is what the path API in the stdlib looks like:

PathBuf::new("my-program")
    .join("assets")
    .join("favicon.png");

I might not have built anything, really. 🫠

It works.