Dnia 2014-08-04, o godz. 08:06:42 Ulrich Mueller <u...@gentoo.org> napisał(a):
> >>>>> On Mon, 4 Aug 2014, Michał Górny wrote: > > In particular, I was thinking we could reuse this syntax: > > > || ( A:= B:= ) > > > to express any-of dependencies that do not support runtime switching > > of providers -- since that is pretty much what := does to slots. > > This would save us from creating a new syntax like '||= ()' [1]. > > Please don't, because it makes things pretty much unreadable. If you > want an operator like || ( ) but without runtime switching, then > define one (e.g., <<= or ||= as suggested in [1]), but don't try > to inherit properties from its children. Reasonable. However, as I see it, we'll end up having up to four different operators: - || that is deprecated yet everyone will still use it (like they don't use :* right now), - ||* that will be used scarcely, - <<= that would be the preferred variant for compile-time switches yet many people will not use it because it has different characters than '||' [we could try maybe '||<' so that people will still see it as replacement for '||'], - ||= that most people would use forgetting about '<<=' [or '||<']. So, banning '|| ( A:= B:= )' in a future EAPI sounds reasonable. However, there's still the matter of setting current Portage behavior because I don't we should keep the non-predictable magic. What should be the current behavior then? Should we assume that all '||' are not well-defined and need to be compile-switchable? Or try to invent heuristic like I suggested? -- Best regards, Michał Górny
signature.asc
Description: PGP signature