Reference

Appendix D: What QF Code Doesn't Do Yet (as of 1.1.0), and Why

This appendix is deliberately factual, not aspirational. It documents QF Code 1.1.0's real boundaries, drawn on purpose in most cases, still open in progress in a few others. If you want the more personal case for where the language is headed, that's chapter 16. This is just what's true right now, and this appendix gets updated every time QF Code does.

Classes and Objects

QF Code has no class, no object, no new, no inheritance. Every value you've worked with in this book, numbers, strings, booleans, arrays, has been enough to build a complete game. That's on purpose: object-oriented design is a real, useful idea, but it's also one more layer a beginner has to learn before writing their first working program. QF Code puts that layer off entirely for now, so nothing stands between you and running code. The words class, object, extends, new, and this are already reserved, held in place for if and when this changes.

Closures

A function in QF Code can't reach into another function's local variables just because it's defined nearby, chapters 6 and 11 both flag this directly. Closures are a genuinely useful pattern in most modern languages, but they also make it harder to answer a simple question: what can this function actually see? QF Code trades that flexibility for a scope model you can hold in your head in one sentence, a function sees its own locals and the globals, nothing else.

Modules and Imports

Everything in QF Code lives in one file. There's no import, no export, no splitting a program across multiple source files. For a project the size of the one you built in this book, that's not really a limitation, it's just how the language currently works. import, export, and module are reserved words already, so this is a known direction, not a permanently closed door.

Reading and Writing Files

QF Code programs can't read from or write to files on your computer. Everything a program knows, it has to get from input() or build itself. This is on the project's own backlog, not a permanent design decision.

Canvas and Sprite Graphics

Output in QF Code is text only, the output panel prints lines, it doesn't draw shapes, images, or sprites. If you want a visual game with graphics instead of a text adventure, QF Code 1.1.0 isn't there yet. This is also on the backlog.

Individual Key Detection

There's no getkey() or keypressed(), no way to react to a single key the instant it's pressed. input() always waits for a full line of text and the Enter key. Real-time, arcade-style input isn't something QF Code supports yet.

wait()

You met sound() and bell() in chapter 12, and learned that both block your program until they finish playing. A proper wait(), a way to pause for a set amount of time without blocking everything else, doesn't exist yet either. It's meant to arrive alongside a fix for the related issue below.

Stop Can't Interrupt sound(), bell(), or input() Mid-Wait

Chapter 12 already covered this directly: once sound() or bell() starts playing, or once input() is waiting for the player to type something and press Enter, the Stop button can't interrupt it. This is a known, documented gap, not a hidden one, and fixing it is linked to adding wait() above.

Text Color

There's no color() or resetcolor(). Output in the panel is a single, fixed style, you can't make one line red and another green. This is on the backlog as well.

A Note on Standalone stop()

Appendix A already covers this in practical terms: a standalone stop() line, on its own, doesn't currently behave as cleanly as the language intends. Calling it from inside an expression works correctly. This is a known defect in the current reference shell, not an intended limitation, and it's expected to be corrected in a future release.

Reserved, But Not Yet Real

A handful of words are already off-limits as variable names, held in reserve for features that don't exist yet: class, object, extends, new, this, import, export, module, async, await, list, map, and set. None of them do anything in 1.1.0. Their presence on this list is itself a small promise about where the language is headed, without committing to exactly when.


Copyright © 2026 Edison Mooers. Published by Gibidda Press. Free for personal learning and qualifying noncommercial educational use. Commercial training, organizational use, redistribution, and adaptation require written permission. Full use terms.