1 |
>>>>> On Fri, 11 Nov 2016, Michał Górny wrote: |
2 |
|
3 |
> Most of your comments don't make sense if you are commenting on the |
4 |
> actual proposal. However, it seems that you immediately ignored the |
5 |
> core part of the proposal, and then commented on stupidity of some |
6 |
> distorted, imagined, half-ass proposal you imagined that lacks the |
7 |
> core part. |
8 |
|
9 |
I had merely addressed the following two points: |
10 |
|
11 |
- The proposal would split the behaviour of the existing operators |
12 |
depending on context: a) They ignore the revision when in a [] group |
13 |
but don't when used in the traditional way, and b) syntax is changed |
14 |
unnecessarily, e.g. ~ vs == and = vs ===. |
15 |
|
16 |
- The number of operators is doubled for no good reason. Revisions are |
17 |
not so special that they would justify that. In addition, if we |
18 |
limit the allowed range of revisions to 9999, the need for such |
19 |
operators will go away entirely. The most common cases (namely >= |
20 |
and ~) can be expressed already now, and the rather more rare |
21 |
less-than-or-equal-to-but-ignoring-revision can be expressed using |
22 |
r9999 (in those even more rare cases where a < comparison with the |
23 |
next PV doesn't work). |
24 |
|
25 |
For both points the cost of the syntax change or of introducing |
26 |
inconsistencies doesn't come with any benefit in the form of added |
27 |
functionality. |
28 |
|
29 |
> So, please, keep your comments on topic. If you don't like the |
30 |
> proposal (I didn't expect it to be otherwise), try at least to stay |
31 |
> objective. Because, really, complaining that proposal doesn't have |
32 |
> '~' operator means that you either didn't care to try to understand |
33 |
> it, or that you immediately discarded what you didn't like and |
34 |
> complained on the result you created yourself. |
35 |
|
36 |
> I expected more of you. |
37 |
|
38 |
No comment on that part. |
39 |
|
40 |
Ulrich |