From: MikkelFJ <mikkelj-anti-spam@...1.dknet.dk>
Date: 2001-11-27T11:27:40+09:00
Subject: [ruby-talk:26590] Re: Ruby vs. Python: Decisions, Decisions


"Ralph Mason" <ralph.mason@telogis.com> wrote in message
news:0c4f01c176b5$47eb84e0$0101a8c0@p3...

> I have been working with Win32ole and have also added the ability to
create
> com objects using ruby.  It's the easiest way I have found of creating com
> object thus far. I have some thoughts on using native interfaces in the
> future (all happens with IDisaptch at the moment).  However all things
> considered, untill there is a really good VM the IDispatch overhead is
> probably much compairable to a standard ruby function call.

The issue is not speed but QueryInterface support and the ability to
implement COM client code
in C++ without having to use IDispatch.
For example you may want to implement the IStream interface for a Ruby COM
object such that it can be serialized.
But the client would then typically query for the IStream interface which
will fail.
Calling IDispatch methods manually in C++ is very tedious.
Effectively this means that you can't use the Ruby COM objects in many
applications.

Another easy way to create COM objects are scriplets (I think that is what
they are called).
It's JScript and VBScript objects also using IDispatch.

> There is a bit of a religious war going on about this one.  I am on the
VC++
> side, and I think it is going that way. To me it really opens up the pool
of
> professional window programmers.  One must remember however that ruby has
a
> UNIX background and they are as likely to want to use VC++ for it, as you
> are to want to use AutoConf , make and all those other tools that you
> probably know little about.

You could also argue that it is a pour language that only works on one
platform.
I think Ruby has already isolated most portability issues. Even so I believe
that MSVC support will mature Ruby because it will find some portability
issues and isolate these into the portability layer. A layer that is much
thinner than the full Cygwin platform and a layer which is under Ruby
control.
Occasionally someone makes the point that Windows is inferior because it
doesn't support a construct like fork. While Windows has its flaws, it
actually do have a process creation construct that is more elegant that just
a copy of the entire image like fork does. But it will of course not work
with all the extension modules that uses fork. This was only intended as an
example. The point is that Windows and Unix/Posix are different concepts and
it should be possible to support both. By blindly supporting Cygwin we are
also widening the gap because extension writers will never test their source
against anything but Unix and needless compatibility issues will be
introduced as a consequence.


MikkelFJ