As much as I happen to like (love) Unix environment I don't like
Ruby's relatively strong ties to that world. I like when Ruby is
loaning features (names, regexps, functionality, notion for text file
processing and being a tool itself...).
From my point of view the the language should be quite
(if not totally) neutral to the OS it's implementations are running in.
Of course this is a little bit contrary to the usefulness of language,
since it's great and handy to have plenty of OS specific features
at hand when you happen to need them.
Maybe an example enlights my view a little. There should be no need for
code like this in any libraries. OS specifics should be hidden as far as
possible from the normal developer. And these are really common
things. (cgi.rb)
NEEDS_BINMODE = true if /WIN/ni === RUBY_PLATFORM
PATH_SEPARATOR = {'UNIX'=>'/', 'WINDOWS'=>'\\', 'MACINTOSH'=>':'}
Problem using the code like this become apparent when I'm called
in when otherwise fine working CGIs suddenly don't work at
Tandem, OS/2 or VMS environment (dunno if Ruby has even been ported
to these wonderful oses yet:). Do you think this code works Beos? I don't
know but I doubt it because there's no specified PATH_SEPARATOR.
Do we really want to release new version of the libraries everytime we
spread to the platform which Perl has maybe already contaminated?
I don't have any major ideas how to cope with these things. One idea could
be to define module OS which in turn includes platform dependently module
Unix, Win95, WinNT or Mac etc. These could have two parts (example for Unix)
# common definitions
PATH_SEPARATOR = '/'
NEEDS_BINMODE = false
# platform specific features
include 'OS/Unix/NixSockets' # if the OS happens to support
include 'OS/Unix/Pipes' # OTOH, maybe not even every unix support
these?
To provide backward compatilibity OS-module could "export" all the currently
provided built-in functions to global space.
I doubt if this is enough or even correct direction but it might be some
kind of start.
- Aleksi