On Tue, Nov 8, 2016 at 3:49 PM, M. J. Everitt <m.j.ever...@iee.org> wrote: > On 08/11/16 07:09, konsolebox wrote: >> On Sun, Nov 6, 2016 at 6:52 PM, Michał Górny <mgo...@gentoo.org> wrote: >>> Hi, everyone. >>> >>> Following my previous RFC wrt version operator problems, I'd like to >>> start the second part of the discussion: how to improve version >>> operators in a Future EAPI? >>> >>> I've collected various ideas on operator changes on a wiki page [1]. >>> I've tried to stay open-minded and cover every possibility, even though >>> I doubt some of them would be even considered. >>> >>> I should warn you that some of the solutions are interlinked to each >>> other, and you probably need to look through the whole page first >>> before starting to construct an opinion. For example, specific >>> solutions to most of the problems depend on whether we enable version >>> ranges and in which form. >>> >>> I think we should start by loosely discussing the various ideas >>> on the wiki page. Feel free to also point out any missing ideas >>> or remarks that would be useful there. >>> >>> So, what are your comments? >>> >>> [1]:https://wiki.gentoo.org/wiki/Future_EAPI/Version_syntax_changes >>> >>> -- >>> Best regards, >>> Michał Górny >>> <http://dev.gentoo.org/~mgorny/> >> I also like the idea of moving the operator as it's more consistent >> and opens new doors to other solutions. >> >> As for the use of operator & and |, they're quite good, but I'd prefer >> the use of Gmail's style where expressions placed in () are processed >> with AND, and expressions placed inside {} are processed with OR: >> >> dev-foo/bar[>=1.3&<1.5] dev-foo/bar(>=1.3 <1.5) >> dev-foo/bar[>=1.3&<1.5&!=1.4.1] dev-foo/bar(>=1.3 <1.5 !=1.4.1) >> dev-foo/bar[<1.1|>=1.5] dev-foo/bar{<1.1 >=1.5} >> dev-foo/bar[=1.1*|=1.3*|>=1.5] dev-foo/bar{=1.1* =1.3* >=1.5} >> >> I find it more readable. The former looks too compressed. >> > Ewww, WTF should we use Google as a (bad) example?!
I don't care if it's from Google or not, and you shouldn't as well. Grow up. It's got nothing to do with the solution. > And "bracketising" > rather than explicit operators is bound to cause confusion Subjective, and depends on the person. I quickly adapted to it. > and errors ... What errors? -- konsolebox
