Re: libext

[Rici Lake <lua@...>]

On 4-Aug-04, at 3:44 PM, Asko Kauppi wrote:

> In the spirit of current library naming convention, I propose 'ext.*' 
> to be the namespace for such non-ANSI C extensions.
>
> 	ext.delay()
> 	ext.osx.applescript()
>
> ..and so on

um, why?

assuming delay() implements a sleep operation, why shouldn't it just go 
into os? The idea is, we say here is an optional interface, not 
provided by the standard Lua library; but, if you are going to extend 
the os. library, this is what it should look like:

* os.delay(t, interruptable)

  sleeps for approximately t seconds. Returns a true value; if the
  return value is numeric, it will be the actual duration of the sleep.
  If the second argument is a true value, the function may return
  earlier than the indicated time interval as the result of a signal
  being received.

  If this function fails, it returns nil plus a string describing the
  error. In particular, os.delay(0, true) will return an error if the
  operating system is not capable of interrupting delays, and
  os.delay(0) will return an error if the os library does not
  implement delay.

Now, if this interface is accepted, then it can be implemented to that
interface to some extent on any OS which has that facility. Platform
independent code can test:

  if not os.delay or not os.delay(0) then
    -- perhaps implement it as a busy loop
  end

  if not os.delay(0, true) then -- make sleep times shorter -- end

In fact, if it passed the final stamp of approval, the interface could
be added to the standard os library, always returning an error.

In other words, a clear statement of an *interface* allows for multiple 
compatible implementations. That is what I was trying to get at.

Rici

PD:
In regard to applescript, which strikes me as an interesting project,
I would have thought that osx.applescript would be sufficiently long as
a package name. But that would be a true extension library, with no
expectation of it being implemented on other OS's until someone figures
out that it would be cool to implement Applescript on another platform.

In reply to your other question, do I oppose platform-independence in
itself, my answer is no, I think it is a good idea. I just think it is
not usually done very well.

On the other hand, GUI libraries which abstract away all the cool things
about the Mac OS X interface do bug me. :)