From: Dave Thomas <Dave@...>
Date: 2002-03-21T23:04:55+09:00
Subject: Re: Windows version of Ruby (proposals)

"Christian Boos" <cboos@bct-technology.com> writes:

> > Anyway, Apparently popen works on 1.6.6 so that leaves only fork not
> > working (is there anything else?).
> 
> Ok, popen works, but not Open3::popen3.

Does popen work with "w+" in your version of Ruby under Windows?

I'd add a number of other issues.

- Threading doesn't work correctly
- $? doesn't work in all circumstances
- File mode stuff is strange
- the 'cmd /c' prefixing of stuff run with system is inconsistent

and so on.

However, I'm not sure that I'd want to see (say) 'fork' emulated under
Windows.

I have a vision for the libraries in 2.0 which I'm sure will never see
the light of day.

I'm thinking that there's stuff that is purely Ruby, and there's stuff
that is environment-sensitive. For example, class Hash is class Hash
no matter where it's running. It should be universally available in
all Ruby implementations.

However, class File is different.

    File.open(name, modestring) do |f|
      line = f.read
    end

is universal - it should work on every Ruby platform. So are many
other File methods. However

    File.open(name, modenum, permnum)

is _not_ portable, and so should not be available universally.
Similarly, File.join is portable (if broken under Windows...),
File.lstat is not. File.delete is OK, File.mtime is not.

And then, under Windows, there are a whole lot of missing file
methods, methods that let us access the underlying Win32 calls for
events, ACLs etc.

So, here's my thinking. The basic classes you get with Ruby (Array,
Hash, Dir, File, Process etc) should *only* contain methods that are
guaranteed to be portable across all Ruby's platforms. If you code
using just these, your program will run unmodified and consistently
anywhere that Ruby runs.

Then, we provide a set of environment support modules for those
classes that currently contain non-portable methods. We could have
(for example)

    module SysdepFilePosix
      ...
    end

    module SysdepFileWin32
      ...
    end

Mix one of these into class File and you'll get all the system
dependent calls. You'll also be explicitly marking your code as
non-portable.

Then, to make life easier, you have a global set of files, say
sysdep_posix, sysdep_win32, sysdep_macosx etc, whose whole purpose is
to mix in the system dependent modules into _all_ the classes that
need them.

That way, you'd have control. If you just wanted to add Window's
specific stuff to File, you could do

   class File
     include SysdepFileWin32
   end

If instead you were writing a program which needed lots of Windows
specific features, you'd do

   require 'sysdep_win32'

and _all_ the appropriate classes would be modified (it might even add
in whole new classes, such as Win32OLE).


I think I'd then take this a step further and add a new method to
Kernel called 'sysdep'

   sysdep :win32
      would be the same as 'require "sysdep_win32"'

   sysdep :win32, File, Dir
      would be the same as

        class File
           include SysdepFileWin32
        end

        class Dir
           include SysdepDirWin32
        end

'sysdep' would check that the platform you're running on is compatible
with the extensions you ask for, raising an exception if not.

Using this scheme, we make portability an explicit feature of the
language, rather then trying to impose a half-hearted Unix layer on
everyone.


Cheers


Dave