On Sun, Dec 4, 2016 at 11:22 PM, Kent Fredric <ken...@gentoo.org> wrote: > On Thu, 1 Dec 2016 14:53:51 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> I got similar idea here, but my version is that you don't have to use >> u: or v: > > The entire point of defining it as a prefix-space was to avoid ambiguity, > and leave plenty of room for other such selector prefixes. > > Relying on properties like "is it a number" or "is it text" is a shoddy > heuristic. > > A heuristic that will fail us as soon as we want to add new features in > our matcher syntax. > > Hence, > > <ATOM>[<CONSTRAINT>(,<CONSTRAINT>...)] > > CONSTRAINT: <identifier>:<parameter>(,<parameter>...) > > > Then instead of debates about how we can invent some "new" syntax > where we have to constantly reinvent existing syntax to allow space > for the new syntax, we can just define new identifiers, because we thought > ahead about this problem and gave us wiggle room to add features.
Well that's just it: ease of use and simplicity vs. portability with possible new parameter types in the future; your pick. I'll personally go for the former this time. Also, what kind of added type of parameters would you expect that would be conflicting with USE flags, or other operators? Wouldn't adding another operator be enough, and not an identifying key? I also find that the current features are already mature enough; we're just enhancing it to have better control. I don't expect anything big to be added further. And come to think of it, a parameter with a key can be distinguished differently from a USE flag, because a USE flag wouldn't have a colon, so a parameter with an identifier that defines its class can still be added if with would need it in the future. -- konsolebox
