Users (or lovers) do not get to choose which implementation of
a module they would like to use.
The abstraction is for dealing with portability issues, not
for giving people the ability to choose an alternative
(inferior) backend. The best choice for any platform/situation
should at all times be the *default* for that platform/situation.
If this is not the case; it's a bug (that is easily fixed).
Any module should provide the functionality promised in the docs.
The lover (or user) should not care how, and if [s]he does, [s]he
does still not get to choose.
Also, a related note: duplication of wrapper code is something I
especially wanted to avoid when I first (or should I say ...
"eventually") formed the current architecture.
--HG--
branch : minor
The audio module was not really stable in 0.6.0, it takes very little messing around to cause OpenAL to do horrible things. It should now be much more stable,
and you *should* be able to play/stop/pause/resume/rewind/loop like a madman without disasters. Seek and tell, however, are still not tested and verified for
all decoders, but that's less important. Also, all objects now have object:type() and object:typeOf(), which returns the type name of the object,
and checks whether an object is of a certain type, respectively.