- Don't add bindings yet; when sound effect support is ready, go back and add the bindings then.
- Add bindings now, and set up stub functions that define the sound effect interface, even though there is no code behind the stubs.
It may seem like option number 1 is a clear winner, especially when there's a lot of work to be done - adding empty stubs doesn't look "productive".
The Cold Harsh Reality: Option 1 is very unwise, despite arguments such as "YAGNI" and so on.
Suppose you have several hundred scripts being written in this scripting language, and most of them use sound effects. Now, when sound is added, you have to go back and revisit each of those scripts to add the sound effect code. By contrast, if we choose option #2, we can add the sound effect code as we write the scripts.
Note that this doesn't save us the work of testing the scripts to ensure that the right sounds are played and so on; however, this is just a simple, contrived example. If the interface is more complex, like a physics engine for instance, then it rapidly becomes much more effective to write code to a stub interface as quickly as possible.
One objection here is that option 2 might not work out so well; what if we get part way into implementing the sound effect system, and the interface needs to change? Now all those bindings are wrong, and the scripts that rely on them are wrong, too.
This objection, fortunately, doesn't hold water. All it takes is a quick run of a global-find tool, and we can immediately see all the places that need to be updated to fit the new sound effect interface. In short, it is much easier to refactor a good interface into another, better interface than it is to "refactor" no-code into some-code.
Advice and Summary: Define your interfaces between modules as early as possible, and write stubs for missing functionality. This helps keep track of what exactly is left to do, and prevents small tasks from falling between the cracks. As a bonus, this strategy works very nicely with test-driven development.
Rather than actually having calls to stub functions (which would define a set interface), use some "magic comments" instead that declare consistently what you were trying to do with your sound interface at that point in the file (change panning, play sound, etc). Then when you've got the sound functionality implemented, since you used consistent comments for the same ideas, you may be able to get away with a simple global search/replace ("play sound xyz.wav" becomes audioEngine.PlaySound("xyz.wav")). You might need a special tool to run through the files and do all this, but that's not really that hard to whip up quickly.
This saves you both from having to go back through and rewrite everything when you finally get the functionality, and also from having your stubs define what your interface has to look like before you've put serious thought into the subsystem.