[ruby-core:35095] Re: [Ruby 1.9-Bug#4343] Dir.glob does match files without extension

On Fri, Feb 4, 2011 at 12:11, Jeremy Bopp <[e-mail]> wrote:
> On 02/04/2011 10:33 AM, mathew wrote:
>> % man -s3 glob
[...]
> That implementation is provided by libc:

And libc is part of Unix. The glob() library call is in POSIX.

> As a result, we are free to ignore it, and in fact Ruby must ignore it
> because Ruby has some extensions not supported by this function.

Just because you implement extensions doesn't mean you need to be
gratuitously incompatible with the POSIX interface.

> We don't have such an option when it comes to the case-sensitivity of
> filesystems.

Sure we do. Many software packages implement workarounds for
filesystem case-sensitivity, length limits, character set limits, and
other OS-dependent behavior. To pick three random examples:

http://oreilly.com/catalog/samba/chapter/book/ch05_04.html
http://netatalk.sourceforge.net/2.1/htmldocs/AppleVolumes.default.5.html
http://commons.apache.org/io/apidocs/org/apache/commons/io/comparator/NameFileComparator.html

> The same is true on Windows. he implementation of glob functionality
> is something that the programming environment is able to ignore simply
> by implementing its own.

By the same argument, we can ignore anything and implement it all
again. But people tend to hate languages that do that, like Java.

> urthermore, what you linked does not appear
> to be a generic globbing function.  think it will only work for
> expanding program arguments, so you probably can't use it within your
> program to scan directory contents using a glob.

I didn't claim otherwise. There are other functions for scanning
directory contents, and they also provide globbing at the OS level.
http://msdn.microsoft.com/en-us/library/aa364418(v=vs.85).aspx

> The question that the Ruby community has to answer is how it wants to
> handle something like globbing where canonical tools included with one
> platform behave differently than equivalent tools on another one do.
>
> My argument is that where possible, such as with globbing, Ruby should
> pick a single implementation to be the default on all platforms.

Right. It's the same issue that surrounds many other things, including
processes, threads, locales and internationalization, text encodings,
and so on. That was why I brought up filesystem case-sensitivity as an
example.

There are two basic approaches languages take. The one you seem to be
advocating for is the Java approach, where you try and come up with a
single API that you can implement on every platform. The resulting API
isn't the same as the native OS one, but its behavior is the same
everywhere. Hence Java has its own locales and ignores the OS ones; it
has its own file APIs that are more restricted than the OS ones; and
so on. It limits what you can do in order to ensure portability.

The other approach is the one Ruby generally seems to take, where you
provide the native APIs, and leave it up to the developer to deal with
any platform specific behavior. Hence Ruby provides dbm, etc, fcntl,
openssl, syslog, readline, winole, win32api, and so on, all of which
can make your code non-portable.

Personally, I prefer the Ruby approach. Frankly, I don't care if
Ruby's behavior is different on Windows, because none of my Ruby code
needs to run on Windows. What I do care about is having APIs which
conform to POSIX and let me do all the Unix things I need to do, like
writing to syslog.

> It doesn't matter what the default is as long as it's functional and as
> consistently implemented as possible on the platform.

Oh, but it does matter. When I run a Ruby script and pass it some
fileglobs, I expect it to expand those fileglobs in the normal manner
every other program on my OS does. If it doesn't do that, that will be
a big surprise.

Your "it doesn't matter if it's not the same as the OS, as long as
it's consistent everywhere" is exactly why most people hate Java
applications.

> If Ruby chose instead to implement platform specific quirks by
> default, the script writer would have yet another set of things for
> which he/she must account during development and testing.

That ship sailed a long time ago. Ruby implements all kinds of
platform-specific quirks; library-version-specific quirks, even.
(readline, dbm)

If you want guaranteed uniformity across platforms, you're probably
using the wrong language. You might have luck with JRuby, certainly
the JVM is going to be your best bet for a runtime.

Meanwhile, I don't see any other people eager for MRI to be more like
the JVM. In fact, the trend seems to be the opposite--one of the big
popular features added to Ruby 1.9 was native threads instead of
cross-platform Ruby threads.


mathew
-- 
<URL:http://www.pobox.com/~meta/>