Alec Warner wrote: > Vaeth <[EMAIL PROTECTED]> wrote: > > > (Moreover, in most cases, > > this would not even save some characters, because the variable > > names would have to be much longer...) > > I don't think the variable names are really in scope (we can chose > them arbitrarily).
But you cannot choose them much smaller unless you want to decrease readability even more. > I disagree with less readable; it is less intuitive The point is that in contrast to shell code you need additional pre-knowledge to read or write it. > the syntax looks fine and the syntax is in fact still bash. I do not want to start a discussion now whether this is implicit semantic or sort of an extended syntax - it depends on the point of view. But in any case it involves new (and actually redundant) "keywords" in the ebuild. > However, ebuilds are already > sufficiently complicated by eclass inheritance that reading > many ebuilds is already difficult This is the point. For certain very specialized eclasses like kde or qt this might be inavoidable, but one should strive to minimize these things as much as possible. So an idea how to go into the *opposite* direction is what is actually needed. > and I think this extension does not make that significantly worse. "because we made some mistakes anyway let us make even more..." > Arguing about intentions is not really a compelling argument. Spec It is, if something does not satisfy (anymore) what is supposed to do. > files have more than magic variables too; many have > similar constructs to ebuilds (postinst and prerm phases, file > manifests, etc.) Specfiles and ebuilds are more alike than different. Yes, meanwhile specfiles and ebuilds are very similar which is really a problem: It is not accidental that many users of other distributions prefer to install into /usr/local instead of writing rpms - most users do not want to learn a specification. It is fatal if ebuilds go the same road. The knowledge needed to write or read ebuilds should be kept as small as possible.
