[PATCH 2/3 v2'] xserver: Introduce negated conditions in Match patterns

[Dan Nicholson]

On Sat, Jun 18, 2011 at 12:07 AM, Oleh Nykyforchyn <oleh.nyk at gmail.com> wrote:
> Well, if people are so accustomed to single arguments and "|" as "or",
> what about:
>
> 1) adding logical '&' to logical '|';
>
> 2) "regex:|pat|" = "regex:/pat/" = "regex:%pat% = .... (like sed);
>
> 3) single argument, with multiple conditions (probably regexes).
>
> This way we obtain the same (and even more) functionality.

The issue isn't about single arguments, but rather adding more
features and complexity when they're not necessary. You asked in
another email why we weren't following the UNIX way of allowing more
flexibility if it didn't interfere with the existing functionality.
The reason is because adding that flexibility has more costs than the
initial patch.

1. It makes the code more complex to handle the various cases. This in
turn makes the code more difficult to understand and more difficult to
maintain. This is why Peter's opinion is so important - he's the one
that's going to be supporting this code down the road when drive-by
developers like you and me aren't around. The easiest way to make code
more maintainable is to remove complexity.

2. These changes become part of the Xorg interface, so they need to be
considered carefully. If it becomes apparent in a year that one of
these features wasn't a good idea, the removal of that feature might
not be possible because now there are working setups using those
features. It's not impossible, but breaking people's configurations
should only be a last resort.

3. The added flexibility is more difficult for users to understand and
easier for them to get wrong. The InputClass matching is already
somewhat difficult to explain, so adding more features on top doesn't
make things easier. Furthermore, the users have apparently been happy
with the current functionality because I haven't seen any other
reports that suggesting that they're too limited.

You might call the above points the KISS model rather than the UNIX
model. You have to ask yourself whether these features are needed
rather than if they're possible. When we started this conversation a
month ago, I that a useful feature was adding an optional argument
where you can specify what type of match you're trying to do. Peter
expressed reservations about that and suggested that we stay as close
to the existing syntax as possible. I still feel like that's a useful
feature, but in hindsight I can see how that's not something the
typical user needs. And at the end of the day, Peter's one of the
maintainers of this project, so his opinion carries more weight for
me.

Like I said, I think there's some useful work in these patches, but I
believe the agreed upon end point was getting "regex:blah" supported.
Instead, each iteration of these patches adds more features that push
them further away from getting in.

This is just my opinion, but I think it's a general strategy shared by
a lot of people here. Much of the effort working on X is supporting
interfaces from 20 years ago that nobody wants anymore. New interfaces
and features that increase the amount of code to maintain need to be
reviewed carefully.

Hope that helps and doesn't discourage too much,

--
Dan