[FFmpeg-devel] [PATCH] doc/filters: document the unstability of the shorthand options notation.

Michael Niedermayer michael at niedermayer.cc
Sat Aug 5 18:34:58 EEST 2017


On Sat, Aug 05, 2017 at 03:42:08PM +0200, Nicolas George wrote:
> L'octidi 18 thermidor, an CCXXV, Michael Niedermayer a écrit :
> > This is ambigous and if interpreted litterally
> > then even a scale=320:240 would no longer be guranteed to work
> > but would require scale=width=320:height=240 to be used.
> 
> That is intentional. Note that w=320:h=240 is enough: four characters
> more.

I think you do not realize how annoying this would be in practice

Users do not know all these nuances that one syntax is stable and work
and one works but is not future proof. It also violates the priniple of
least surprise. Aka this fails one of the most fundamental rules of
user interface design


> 
> > the shorthand is widely used and convenient
> 
> It is convenient, but not absolutely necessary. Once in a script, the
> extra function names make it more readable and more robust anyway.
> 
> > That way anything that works will contine to work and one cannot
> > mistakly write a script that uses unstable shorthand options
> 

> Remember that "anything that works will continue to work" is opposed to
> "we can add new features without being burdened by past mistakes".

This comment makes me a bit sad.

It implies that old code is bad without any solid fact, nothing one can
proof, disproof, or fix. And thats not even related here, you
didnt start by wanting to fix a mistake in the order, the changed order
was a side effect of other work.

also my suggestion was to define what is stable now and maintain that
properly and disallow what is not stable. Have a clear interface and
stick to it.

Stable interfaces are important.

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170805/ad59322b/attachment.sig>


More information about the ffmpeg-devel mailing list