Re: Status of lposix?

[Cosmin Apreutesei <cosmin.apreutesei@...>]

On Fri, May 29, 2009 at 11:44, steve donovan <steve.j.donovan@gmail.com> wrote:
> 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.

Gotta be my aggressive tone that triggered that reaction :) Apologies
for that. Also, I consider lfs a good lib -- no probl. w/that either.

>
> People do want to write stuff that works on different platforms, and
> often succeed, which is  the operational definition of portability.

Sure, but are they willing to trade in performance and api coverage?
That was my whole point -- stay focused -- I have no problem with the
goal of portability per se. However, in the case of filesystems, I
don't think you can do or need much more portability above the
built-in io library for ANSI and lfs for PCs without including too
much random choice or leaky abstractions -- just IMHO.

> (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.
>

Operations on paths is part of the random set of choices I was talking
about since Windows and Unix are so different here (slashes, drive
letters, invalid characters, extensions, quoting, escaping, etc.). And
I have a thing with trivial operations implemented in libraries too.
Their place is on the wiki -- also IMVHO.