Re: libext

[Alex Sandro Queiroz e Silva <ventonegro@...>]

Hallo,

Rici Lake wrote:

> 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.
   I've understood that your point is to define standard interfaces for 
common tasks present in several operating systems. But I also believe 
that some form of standardisation begins with the namespace usage.

   That's why I think "ext" has its value. Let's take OpenGL, for 
instance. When you read the OpenGL especification you know that whenever 
a vendor says its product is OpenGL-compliant, everything that you read 
must apply. But some vendors introduce their extensions to OpenGL, and 
there is a definite naming scheme for them (GL_ATI_*, GL_NV_*). If later 
one of those extensions is adopted by several vendors, it's gonna 
receive a GL_EXT_* name. I think that's nice because you only have to 
test for the features that may not be present, depending on the user 
hardware. Those features are marked as extensions.
   Similarly, when you read the Lua Manual you know that everything 
there holds for every ANSI C-compliant platform. There is no need to 
test for anything. But if you need os.ext.delay, you know you must test 
if it exists because of the "ext" in the name. In the end, I think the 
clarity of the name pays off.

-alex