1 |
On pon, 2017-05-01 at 09:38 +1200, kentnl@g.o wrote: |
2 |
> From: Kent Fredric <kentnl@g.o> |
3 |
> |
4 |
> @DEFAULT-ASSUMED allows eclasses to document any implied value |
5 |
> that internal code will assume when the ENV var is undefined. |
6 |
> |
7 |
> @DEFAULT-ASSUMED should typically be used in conjunction with |
8 |
> @DEFAULT-UNSET, but it can be used in conjunction with either |
9 |
> @DEFAULT-VALUE or normal value extraction. |
10 |
> |
11 |
> For instance: |
12 |
> |
13 |
> @VARIABLE: DIST_TEST |
14 |
> @DEFAULT-ASSUMED: "do parallel" |
15 |
> |
16 |
> This inserts an additional suffix to the generated man page heading |
17 |
> line so it renders as follows: |
18 |
> |
19 |
> DIST_TEST (UNSET -> "do parallel") |
20 |
> |
21 |
> But indicates that the value itself is not explicitly set by the eclass |
22 |
> and ebuilds should not assume it to have a value. |
23 |
> |
24 |
> For instance, upon seeing such an indication, ebuild authors should |
25 |
> be able to tell that doing |
26 |
> |
27 |
> DIST_TEST+=" network" |
28 |
> |
29 |
> Would end up producing |
30 |
> |
31 |
> DIST_TEST=" network" |
32 |
> |
33 |
> Not |
34 |
> |
35 |
> DIST_TEST="do parallel network" |
36 |
> |
37 |
> This is primarily for usecases where the variable is not assigned |
38 |
> anywhere in the top level file, but consuming functions imply a value: |
39 |
> |
40 |
> has "parallel" ${DIST_TEST:-do parallel} |
41 |
|
42 |
Well, I don't think there's really a good reason to expose this |
43 |
in an explicit tag. It's going to be a little bit confusing at least |
44 |
(your rendering isn't immediately obvious for users), and I don't really |
45 |
see the problem being solved here. |
46 |
|
47 |
As far as I can see, it applies to quite a specific corner case, when: |
48 |
|
49 |
a. you want to assume a default value for the variable, |
50 |
|
51 |
b. the assumed default is simple enough to be expressed directly, i.e. |
52 |
unconditional, |
53 |
|
54 |
c. but at the same time you stil want to keep it unset in global scope |
55 |
for some reason. |
56 |
|
57 |
Even if you have a very good reason for all the three conditions to be |
58 |
met, I think that in the majority of cases you will need to explain what |
59 |
particular values mean. |
60 |
|
61 |
That being the case, I don't really see an advantage of explicitly |
62 |
listing default value with potentially confusing syntax when the same |
63 |
problem was already solved in a readable and non-confusing way by |
64 |
explaining it in the body. |
65 |
|
66 |
In other words, I don't think that: |
67 |
|
68 |
DIST_TEST (UNSET -> "do parallel") |
69 |
|
70 |
is more readable than: |
71 |
|
72 |
DIST_TEST (UNSET) |
73 |
... |
74 |
If unset, "do parallel" is assumed. |
75 |
|
76 |
-- |
77 |
Best regards, |
78 |
Michał Górny |