1 |
Alec Warner wrote: |
2 |
>> No, it's entirely objective. GLEP 55 clearly shows how the filename |
3 |
>> based options are objectively better than anything else. |
4 |
> |
5 |
> But the decision will not be based entirely on objective merits |
6 |
> (although I will concede that EAPI in filename is the 'best' technical |
7 |
> choice). |
8 |
|
9 |
(Jeez, I hate to add another to this thread, but this way of defining |
10 |
'technical' bothers me) |
11 |
|
12 |
Along the lines of what Roy so eloquently expressed, I think it's |
13 |
important that we do not divorce *design* from *technical*. The |
14 |
decision of where to place the EAPI is a design issue, and many of us |
15 |
here clearly believe that it is *not* good design to put this kind of |
16 |
metadata in the filename. Therefore, the statement that it is the |
17 |
'best' technical choice is not objectively true. |
18 |
|
19 |
Technical issues of performance and efficiency can be addressed when |
20 |
proper design has been done beforehand. Part of the purpose of the |
21 |
implementation (after proper design is in place) is to address |
22 |
performance and other related issues. And part of the design is how we |
23 |
define the *interface*. The filename is clearly part of the interface. |
24 |
It is part of how devs (and users) interact with portage when writing |
25 |
ebuilds. Much of the argument for EAPI in the filename has been |
26 |
motivated by a perceived implementation benefit of speed, as if there |
27 |
were no other solutions (which is naive). As Roy suggested, if all |
28 |
engineering decisions were based purely on pragmatic "ease of |
29 |
implementation" factors, we'd have a lot of ugly designs/interfaces out |
30 |
there. |
31 |
|
32 |
It may be easy (although incorrect) to dismiss elegance/design/interface |
33 |
issues as "non-technical", but I maintain they actually *are* technical |
34 |
matters of great importance. I've been an engineer for over 20 years, |
35 |
and I have seen the pitfalls of taking the quick-and-dirty approach just |
36 |
to slap a new feature into a software app. I've seen how such hasty |
37 |
design mistakes can cause great pain and regret for a long time after. |
38 |
Let's get the design right, first. For what it's worth, GLEP 55 does |
39 |
now provide an option (#3: Easily fetchable EAPI inside the ebuild and |
40 |
one-time extension change) that demonstrates good design. |
41 |
|
42 |
-Joe |