Re: Status of lposix?

[steve donovan <steve.j.donovan@...>]

On Fri, May 29, 2009 at 9:51 AM, Cosmin Apreutesei
<cosmin.apreutesei@gmail.com> wrote:
> Abstractions leak. You can't just "create" portability with
> abstraction. The lowest common denominator is _designed_, and turns
> into a standard (there are other ways to get there too), then
> implementors _follow_ that standard and achieve portability. In that
> order. Taking a Windows fs lib and a Unix fs lib and abstracting away
> the differences can be fun, especially in lua, but won't get you
> portability, just leaky abstraction.

lfs is reasonably portable and provides a clean interface, although
its stat() interface is going to be necessarily limited, since Windows
files don't have those interesting executable bits etc.  There was
that very valid point that was raised, that the Unix way of checking
files (iterate over directory, call stat) is inefficient for Windows,
which provides an iterator which gets that information for you.  So,
there's something else that gets hoisted up into the library.  I don't
see a problem with that.

People do want to write stuff that works on different platforms, and
often succeed, which is  the operational definition of portability.
(The old Unix meaning of 'portability' was 'can be compiled on
anything that's like Unix')

Abstractions leak, we know this, just as metaphors and models have limitations.

The approach I've taken in Penlight is simply to follow a de-facto
standard for file and path manipulation provided by Python. It is
probably not the best, it isn't the most elegant, but it was a
concrete target to aim for.  A lot of path operations suggested in
this thread are fairly trivial to knock together if you have a solid
set of primitive operations.  We should aim for a 'spanning set' of
operations that are composable, and compact enough to fit in the
average programmer's head.

steve d.