Re: libext

[Rici Lake <lua@...>]

On 5-Aug-04, at 9:36 AM, Alex Sandro Queiroz e Silva wrote:

> 	I don't like much this idea, because I like the idea of a standard 
> library that works all the time. Having to remember the features that 
> may not be present and test for them could become a headache in the 
> future. I like the idea of a "ext" library though, which could install 
> itself inside the "os" namespace.
>
> os.ext.delay()

Some criteria are necessary, to be sure. I wouldn't put any extension 
in the os. library, for example, unless there was a reasonably chance 
that it could be implemented on most OSs.

Putting extensions in an os.ext. library doesn't solve the problem of 
tesing. You still have to test for the os.ext library *and* you have to 
test to see if the particular extension you want is there, unless 
*every* extension goes into a separate subsublibrary, which gets 
ridiculous (or at least javaesque).

So it seems to me that .ext adds no value. Even in the standard os 
library, there are some interfaces which may fail on certain platforms, 
so you cannot even say that .ext is a reminder that the function may 
not work.

Furthermore, as we have seen many times with "experimental" features, 
there is a tendency to deploy them before they get "officially 
renamed", and then you are stuck with forever supporting, for example, 
application/x-url-encoded. Other examples abound.

My point is that if the interface is properly defined and documented, 
and accepted, it can be included in a standard library even as a stub. 
If the interface is not properly defined and documented, things are a 
mess wherever the library goes. Requiring well-written and 
well-thought-out interfaces prior to inclusion in standard libraries is 
one motivation for people to think through and document their 
interfaces :)

I know this is counter-cultural at this point in time, when developers 
seem to feel that it is sufficient to point a documentation tool at 
their header files or java source. This is exactly backwards, imho -- a 
good library comes about because the interface was thought through 
first (probably after some experimentation: good design requires three 
rewrites, in my experience).

Rici, who is currently struggling with a big library whose so-called 
"documentation" was generated by doxygen.