From: MikkelFJ <mikkelj-anti-spam@...1.dknet.dk>
Date: 2001-10-07T09:22:27+09:00
Subject: [ruby-talk:22181] OO system interfaces was Re: The Windows question still remains...


"Aleksei Guzev" <aleksei.guzev@bigfoot.com> wrote in message
news:001301c14da4$73b3e7f0$665e0cc3@p32...

free to use all the Windows features. That's why I started translating
> Windows API to Ruby. I do not wish a new API to windows, threads  etc,
> but I'd like to access the Windows' functions as they were inteded to be
> accessed. It's not a good idea to use an additional layer to access
> Windows API.

With all due respect for your porting efforts which are useful in their own
right, I actually believe there is a reason for adding an additional layer.
Win32 were designed rather object oriented, although it was given a flat API
interface.
Microsoft has added several object or component oriented interfaces to parts
of Win32 in the shape of COM interfaces and Windows Management
Instrumentation objects (an OO layer above COM).
Their plan was to migrate all system interfaces into COM interfaces, WIN32
more a less being an alternative for legacy reasons.
With the recent .NET approach from the sideline, I belive both COM and .NET
objects will be primary system interfaces.

In that light, it makes perfect sense to add an OO layer on top of the Win32
API - and Ruby is well suited for it.
However, I have a better suggestion:
The .NET class library actually made a heavy effort of making a
crossplatform interface. Some rather Windows OS specific features are simply
absent or replaced with more general constructs. Like Java, but closer to
the OS I reckon.

Therefore - I might be interesting to study the efforts put into the .NET
class design and possibly port some of this to Ruby. In the spirit of Ruby
this API would then be supported cross-platform - to the extend it is
implemented on various platforms.
This can possibly also be a way to deal with native threads.
Furthermore - it is on track with both the .NET and the mono project.

Mikkel