[Gnash-dev] Microphone and Camera

[Benjamin Wolsey]

I've restored the breakage to the testsuite and fixed AS implementation
errors in Camera and Microphone classes myself, so that trunk is now
again almost in the state it should always be in.

There are now test failures in misc-haxe.all/classes.all. The Microphone
tests are wrong, so the first thing to do is fix them by testing with
the pp. Then see which ones Gnash still fails.

The fixes to those two AS classes mean that there are now more places
where the testsuite will fail if anyone messes these classes up. There
never was an excuse for not running the *whole testsuite* before *every
commit to trunk*. Now you are even more likely to be caught out if you
don't do it.

It would save a lot of time now and later if some changes were made to
the Microphone and Camera classes. I've explained before why it isn't a
good idea to use inheritance because of ActionScript's weak typing.
Another reason is that you cannot use multiple (or indeed any)
inheritance and expect to create objects dynamically that inherit from
the derived class. This is more or less what we have now (without
multiple inheritance):

struct Input {};
struct Gst : Input {};
struct Ffmpeg : Input {};

#ifdef FFMPEG
struct Camera : Input {};
#else
struct Camera : Gst {};
#endif

In the first case, Camera is a subclass of Input like Gst and Ffmpeg,
and there is no way of using polymorphism to generate a single Camera
that inherits from Gst *or* from Ffmpeg. That means we would always be
stuck with two separate implementations of camera_as_object. It also
removes much of the advantange of having a base input class at all,
because only the derived class functions are ever used.

The simple change to using composition, i.e. having an Input* member of
Camera, would mean that the same Camera class could use Ffmpeg or Gst.
Either provide access via and accessor for the Input member, or for all
the relevant functions. This would remove the need for all ifdefs in
those Microphone and Camera implementations.

There is no need to implement any functionality in Ffmpeg at all. If the
base class contains default methods (and most of the object data is
stored there anyway), the code will work equally well and the testsuite
will pass for both Ffmpeg and Gst, even if the Ffmpeg implementation
does nothing, or doesn't even exist.

bwy

--
Free Flash, use Gnash
http://www.gnu.org/software/gnash/

Benjamin Wolsey, Software Developer - http://benjaminwolsey.de

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil