On Mar 8, 11:42 am, Chad Perrin <per... / apotheon.com> wrote:

> > A Windows-only fork would have several advantages.
>
> > First, I could use the native Windows API functions for everything and
> > not worry about *nix compatability.
>
> That's not a benefit of a Windows-only fork -- it's a "benefit" of
> deciding you're not going to code for portability.  Choosing a
> Windows-only language is part of making the decision to ignore
> portability, not a free pass so you don't have to make the decision.

Fair enough, but it would mean that I could drop the cruft of
supporting 95/98/ME, too. It would be an "NT Family only" fork.

> > Second, I could modify the core classes as I see fit to take advantage
> > of the Windows API functions.
>
> Why can't you do that with Ruby

Patches for Windows are a colossal pain (it requires modifying 3 files
as far as i can tell) and, in my experience, major patches are
unlikely to be accepted anyway.

> -- or just create mutant relatives of
> the Ruby core classes?

I've done that already to some extent with Win32Utils. But, to get
Unicode support, I would effectively have to redefine *every* method.

> > Third, I could alter the API of some of the Ruby core classes and/or
> > modules where it makes sense to do so on Windows (i.e. get rid of the
> > Unix-isms, add  Windows-isms).
>
> You could do that anyway.  Feel free to create Windows-only modules.

But you're forgetting the stdlib alterations.

Not to worry, though. I'm not really going to pursue it. Not without
VC funding, anyway. :)

Regards,

Dan