David Leverton <levert...@googlemail.com> posted 200905161059.53706.levert...@googlemail.com, excerpted below, on Sat, 16 May 2009 10:59:53 +0100:
> But the point isn't that we want to be able to do those things. The > point is that if the EAPI is in the filename, it's blatantly obvious > that it has to be static, but adding strange and unintuitive > restrictions on which shell constructs can be used is, well, strange and > unintuitive. Has it really come down to this? I mean, for the longest time, the main (among many) boosting claim seemed to be that the speed difference between in-file and in-filename made the former prohibitive in practice. Perhaps the benchmarks the council asked for are disproving this. I don't know but I know I sure see a lot less of that claim, call it a deemphasis if you will, now, only that the filename method (i.e. glep55) isn't slower. <shrug> Now, the main argument seems to be that glep55 filename based eapis are "more intuitive". The argument was originally made that a simple highly specified EAPI= declaration in the file itself was too restrictive of all the ways it could be specified now -- until it began to be pointed out every time the argument was made that the filename method was very similarly restricted. Now that argument has been debunked and no longer works as it did, so it seems the reasons now being presented are what they have left, that the filename restriction is "blatantly obvious", while the in-file EAPI= restrictions are "unintuitive". I'd argue no, it's no more unintuitive than any other format definition choice. It's the basic format definition, using the long accepted method of "magic values" at a "magic location" to define the format version. That's very basic definitional, restricted only to the degree necessary for practical application of the definition. Therefore, it's not unintuitive, or at least, certainly no more so than arbitrarily defining it to be in the filename instead, because "intuitive" now gets defined by the format definition at an extremely basic level, well below the level at which all the "intuitive or not" fancy stuff gets addressed. Regardless, the practical effect is the same, (relatively) severe restrictions from the extremely loose definition we have now. The restrictions are even similar. Thus, it's only an argument over how "intuitive" it is, and, well, a stable "base" definition that's unchanging is certainly going to look more "intuitive" than say, what features are in each EAPI, the much more difficult and "unintuitive" thing devs are already trying to track. Anyway, if it has come down to arguing how intuitive the two opposing options may be, that's GOOD news indeed! It means the important questions are, one way or another, getting resolved. After that, ultimately, it's a council judgment call, and we're actually getting close! Unfortunately, "close" is a relative term. =:^( Realistically? I'm not sure it's going to resolve by the end of this council's term, but provided the elections don't shake things up too badly, it actually looks possible to do so reasonably within the /next/ council's term. We've never actually had it (realistically) that close before! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
