> 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.
>
Hi Nick,
if we use identifiers that do not say anyting we of course can change
the meaning of this identifier without any probelms.
But I think the advantages of identifiers who say something about the
thing they identify is much more better than numbers.
The second thing is that if we use a string as identifier we do not have
to change sane.h all the time when we add a new format.
That can make much problems, here only one example:
( We will not distribute all frontends and the backends together in the future,
this is the reason why xsane is not included into the sane package. )
You can not find out with precompiler test (#ifdef ...) if there is a member
in the enum or not. So if you try to compile a frontend that tries to uses
a new frame format (SANE_FRAME_NEW_XYZ) but that one is
not defined in the enum you get much problems that are not easy to
solve.
Bye
Oliver
-- EMAIL: Oliver.Rauch@Wolfsburg.DE WWW: http://www.wolfsburg.de/~rauch
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com