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. > 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.
pgpYBkbFhyT7n.pgp
Description: OpenPGP digital signature
