| 1 |
On 7/25/19 4:29 PM, Michał Górny wrote: |
| 2 |
>> |
| 3 |
>> * In the md5-cache entry, maybe use a common prefix like EXT_ for the |
| 4 |
>> extra keys in order to distinguish them from normal keys. |
| 5 |
> |
| 6 |
> Yeah, I was thinking of something like '__ext_foo', or '__ext[foo]'. |
| 7 |
> |
| 8 |
|
| 9 |
What are the pros/cons of this? The names refer to global variables, so |
| 10 |
they should already be safely namespaced, right?. |
| 11 |
|
| 12 |
There is a possibility that an eclass variable name (e.g. PATCHES) could |
| 13 |
become standardized at a later date. If that happens, we could wind up |
| 14 |
with both FOO and __ext_FOO in the cache, and tools would have to figure |
| 15 |
out what to do with zero, one, or both present. (This has happened in |
| 16 |
email/web protocols when an X-Foo header was standardized.) It's not the |
| 17 |
end of the world, but someone would have to stop and think about it. |
| 18 |
|
| 19 |
Finally, just having the name be predictable so that I can grep '^FOO=' |
| 20 |
without having to care where it came from is nice. |
| 21 |
|
| 22 |
OTOH for testing, and for figuring out why these weird variables are |
| 23 |
showing up in my cache, the prefix would help. |
Archives