> I see no advantage of using numbers for it, but it makes it much more
> easy for the frontend programmers to support new formats and it is
> much more easy to add new formats to the standard because you do
> not need a new sane.h file.
I still like numbers, not least because we'll have to keep them around
anyway for compatability with SANE 1.0
Also, Andreas is wrong to portray the enumerations as only having down
sides. Look in your GIMP header files some time to see broken formats
replaced by renaming the appropriate enums. This makes it possible for
Gimp to be backwards compatible with buggy versions of Gimp (!)
This mechanism has also been used by IJG libJPEG and by libTIFF
Example for SANE
Some time after SANE_FRAME_BLAH is established we discover that the
existing backends and frontends have co-incidentally implemented
the same wrong behaviour. We could then re-write all the software,
and require users to upgrade immediately, or we could just do this:
SANE_FRAME_BROKEN_BLAH = old value of SANE_FRAME_BLAH
SANE_FRAME_BLAH = newly issued frame type number
Which makes it possible to auto-detect broken frames from the old
broken backends in a new frontend, and correct for it (if possible)
or at least avoid nasty surprises.
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com