The IMPLEMENTATION section of the RFC is supposed to be mandatory, but
there have been an awful lot of RFCs posted that have missing or
evasive IMPLEMENTATION sections. I found more than 39% of all RFCs
have a missing or incomplete implementation section.
Here are the results of my survey. Of 166 total RFCs: (numbers 1-167,
except #41)
RFCs: 24 25 69 70 80 81 106 128 132 147 148 159 164
These 13 ( 8%) had very brief IMPLEMENTATION sections that
didn't contain any substantive discussion. In these cases I
judged that an implementation section would have been
desirable. Some RFCs do not need implementation sections. I
have enumerated these separately below.
In some cases the section was actually flippant. #147 is a
good example here.
RFCs: 21 26 62 84 88 110 112 131 136 137 140 149 162 165 166
These 15 ( 9%) had no IMPLEMENTATION section at all. I was
surprised that the librarian had even accepted these, since
that section is not described as 'optional' in the RFC format
document.
RFCs: 97 100
These 2 ( 1%) said that implementation discussion was beyond
the scope of the RFC, which I don't understand, since it
clearly *is* part of the scope of the RFC.
RFCs: 8 12 21 23 31 40 53 54 55 58 59 72 73 93 103 104 120 133 134 150 167
These 21 (13%) contained remarks about the author's ignorance.
For example:
#53: "Dammit, Jim, I'm a doctor, not an engineer!"
#93: "I'll leave that to the internals guys. :-) "
#40: "I've no real concrete ideas on this, sorry."
RFCs: 5 6 14 30 39 45 64 75 87 89 109 113 115 160
These 14 ( 8%) contain IMPLEMENTATION sections, but do not
actually discuss implementation. Instead, they contain more
or less detailed discussions of the *interfaces* to the
proposed new features.
I recommend that a change be made to the RFC metadocuments to
make the purpose of the implementation section clearer.
This makes a total of 65 (39%) that have missing or bogus
implementation sections.
Of the remainder:
RFCs: 1 2 3 4 10 11 13 17 18 19 22 27 32 35 36 37 38 42 43 44 46 47 48
49 50 51 52 56 57 60 61 63 65 66 67 71 78 79 82 83 85 86 90 92
95 96 98 99 108 111 116 117 119 121 123 124 129 130 135 138 139
142 143 145 146 151 152 153 154 155 156 157 158 161 163
These 75 (45%) appeared to contain explanations of
implementation issues. In some cases the discussion seemed
clearly deficient, but that's not the problem I'm trying to
address in this message. I did not try to judge whether or
not the discussion was cogent or to the point, but only
whether a good-faith effort had been made to identify and
discuss the issues.
RFCs: 7 16 33 34 68 74 76 77 91 94 102 107 114 118 121 144
These 16 (10%) said something along the lines of "The
implementation should be straightforward." I did not try to
judge whether this was actually true.
RFCs: 9 28 29 101 105 125 126 127 141
These 9 ( 5%) don't contain any substantive discussion of
implementation issues, because it is not appropriate or
necessary. For example, #125 is "Components in the Perl Core
Should Have Well-Defined APIs and Behavior" and #28 is "Perl
should stay Perl".
Summary:
Have implementation section: 75 (45%)
Should have implementation but do not: 65 (39%)
"Implementation is straightforward": 16 (10%)
Don't need implementation section: 9 ( 5%)
I don't think this is a good thing. People are proposing all sorts of
stuff without thinking even a little bit about how it might be
implemented. I think the proposals might be more carefully thought
through if the proposers were not allowed to evade thinking about
implementations.
Not everyone knows enough about Perl's internal design or about
programming design generally to be able to consider the issues. I
suggest that these people should write to the approrpriate working
group chair and ask to be put in touch with someone who can help them
with the internals sections of their RFC. Then they can work out some
of the details together and we might avoid some of the more obviously
half-baked suggestions.
