As you describe in programming, a stub is a
development construct. With concurrent development by
more than one programmer working together toward a
common goal, user "Zero0000" may create a stub, which
is expanded upon by user "Lance6Wins" and brought to
release quality by user "Viajero". The process may
be iterative and each may add at various times.
Seems to map very well to the concept of stubs in
Wikipedia.
Lance6Wins.
(names chosen totally at random by "the Forlorn Hope".
hmmm...do we have a wikipedia page on "the forlorn
hope"? bit of british army history there.)
--- dpbsmith(a)verizon.net wrote:
I have some guesses about the evolution of the
"stub" concept on Wikipedia
and am seeking information from oldtimers as to
whether my guesses are right.
I first encountered the word "stub" in a technical
context. About the time I
started hearing about "top-down programming," which
would have been, um, the
1980s, I also started hearing about "stubs."
When you are following the top-down methodology, you
often encounter a
situation where subroutine A calls (and hence
depends on) subroutine B. Yet
you want to write and test A before B is written.
For example, subroutine A might call subroutine B to
find out whether a
device is ready before trying to output to it.
Subroutine B is
absolutely vital to the finished program, but for
purposes of writing and
testing A you just write a "stub" version of B which
doesn't actually talk to
the device, but just says "the device is ready."
In this context, a stub is a piece of temporary
scaffolding that is put in
place solely to allow work to proceed, which is not
a part of the finished
product, and which must be removed and replaced with
the real subroutine
before the product is released.
I fantasize that it is a couple of years ago, and
that there are enormous
numbers of articles that anyone can see need to be
written, and that I have
decided to write about (say) echinoderms. As I start
to write, say, an
article on "Echinodermata," I realize that I will
eventually want to write
and link to Asteroidea, Echinoidea, etc. So I create
stubs for these, with
two things in mind. First, I have at least some
intention of going back and
actually writing those articles. Second, I know that
there are other people
who know as much or more than I do about
echinoderms, and may prefer to write
the article on Asteroidea myself rather than waiting
for me to do it.
So the stub serves _three_ purposes: a reminder to
everyone that there's an
article that needs to be written, an implied
statement that I sort of plan to
write that article when I get around to it, and an
implied invitation to
others that if they feel like working on this
_before_ I can get around to
it, they should just jump in.
I notice that "The Perfect Stub" clearly presents
stubs in the context of an
intention by the creator of the stub to continue
personally working on
expanding the stub. It seems to suggest that the
expected timeframe for
this expansion is a few weeks; that is, it should
reasonably expected that
the stub contributor will keep nibbling away, adding
small accretions to the
stub, and that if a few weeks have elapsed and
nobody else has taken on the
job of writing the article the stub creator should
assume that nobody else is
going to, and they should write the article
themselves.
Part and parcel of this viewpoint is that a stub is
not useful in itself. As
with the programmer's stub, it is just a temporary
expedient to allow work to
continue, and must be replaced with a real article
before "release."
Does this imaginary view of mine correspond to an
historically correct
description of the mindset with which stubs were
viewed a couple of years
ago?
_______________________________________________
WikiEN-l mailing list
WikiEN-l(a)Wikipedia.org
http://mail.wikipedia.org/mailman/listinfo/wikien-l
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!