On Mon, Dec 5, 2016 at 1:41 AM, Kent Fredric <ken...@gentoo.org> wrote: > On Mon, 5 Dec 2016 01:21:34 +0800 > konsolebox <konsole...@gmail.com> wrote: > >> 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. > > Its just frustrating for me, because its not the first time I've had this > conversation. > > I have some vague memory of the last time we changed dependency syntax, > and I said then something along the lines of "hey, why not get this right so > we don't have to have this again later" > > And here we are, bike shedding, debating new syntax classes without forsight.
I would love to prove this with a proof-of-concept, but I don't have the motivation yet. I also did it once, it wasn't helpful. >> would be conflicting with USE flags, or other operators? Wouldn't >> adding another operator be enough, and not an identifying key? > > The difference between an "operator" and an "identifier" is one of the two > hails from a limited set of punctuation marks, and sometimes the order is > important. > > For example: 5 + 6 and add( 5, 6 ), are functionally equivalent, however, > the former hailed from a narrow supply of characters which people saw fit > to use for everything, and now you have fun problems in JavaScript where > "+" does more than one thing depending on conditions. > > Punctuation is powerful, but its a limited resource that serves itself > best when used sparingly. I agree with that, but we have to consider balancing it a bit sometimes. -- konsolebox
