[FFmpeg-devel] [RFC] av_set_string() semantics

[Stefano Sabatini]

On date Saturday 2008-05-24 21:11:45 +0200, Michael Niedermayer encoded:
> On Sat, May 24, 2008 at 07:56:04PM +0200, Stefano Sabatini wrote:
> > On date Saturday 2008-05-24 17:53:55 +0200, Michael Niedermayer encoded:
> > > On Sat, May 24, 2008 at 05:33:26PM +0200, Stefano Sabatini wrote:
> > > > On date Saturday 2008-05-24 15:00:40 +0200, Michael Niedermayer encoded:
> > > > > On Sat, May 24, 2008 at 12:22:19PM +0200, Stefano Sabatini wrote:
> > > > > > On date Saturday 2008-05-24 12:00:27 +0200, Stefano Sabatini encoded:
> > [...]
> > > > And this fixes the second problem, with this now:
> > > > ffmpeg -bt -1-2-3-4-5-6-7+100
> > > > 
> > > > doesn't issues an out of range value error.
> > > 
> > > and iam still curious who and why would write
> > > -bt -1-2-3-4-5-6-7+100
> > > in the first place ...
> > 
> > That was quite a pathological case, anyway who knows?
> > 
> > And the user could for example want to specify the more mundane
> > command:
> > ffmpeg -bt -1+default
> > 
> > then discover with surprise that it doesn't work, while the command
> > ffmpeg -bt default-1
> > 
> > logically equivalent from her point of view works just fine.
> > 
> > Secondarily: when you're documenting such things, you and the reader
> > prefer to read something like this:
> > 
> > * takes as an argument a string representing a sum of addends, they're
> >   added and the result of this sum is set into the value if it
> >   respects the value constraints.
> > 
> > rather than:
> > 
> > * takes as an argument a string representing a sum of addends, each
> >   partial sum is set in the option if it respects the value
> >   constraints (so the command will fail even if the total sum is valid
> >   but a subtotal cannot be validated against the value constraints,
> >   nonetheless the value in the context will result set to the previous
> >   valid subtotal).
> > 
> > The first behaviour is straightforward, the second leads to plenty
> > corner cases which lead to obscure bugs/glitches, when it isn't
> > documented it is even worse.
> 
> Takes an numeric scalar optionally with a SI postfix or a named scalar.
> behaviour with +- infix operators is undefined.
> 
> Takes an numeric scalar or a named flag. prefixing a flag with + causes
> it to be set without affecting the other flags, - similarly unsets a flag.
> 
> No corner cases, not messy, not even hard to document.
> My question is simply where the extra fearures (which mostly but not
> completely work ATM) are usefull.
> We have to weight the awnser to this question against the complexity
> of a imlpementation of it.

Mmmh... if this is the assumed behaviour then I'm fine with it (but we
should document it).

> That is of course if you can implement it with no extra complexity then
> it would be fine without any explanations why its good for. But so far, 
> the suggestions of hash tables and and and ... really are quite a heavy
> thing compared to the _complete_ lack of a single realistic use case.
> Maybe it is usefull in some cases, but so far noone pointed to any ...
[...]

Regards.
-- 
FFmpeg = Faboulous & Faboulous MultiPurpose EnGraver