From: Ralph Mason <ralph.mason@...>
Date: 2001-11-27T11:59:47+09:00
Subject: [ruby-talk:26595] Re: Ruby vs. Python: Decisions, Decisions

From: "MikkelFJ" <mikkelj-anti-spam@post1.dknet.dk>
> > 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

The original post qureied the speed of calling com from Ruby.

> 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.

Calling IDispatch from another higher level language like VB, VBA, Jscript,
VBScript  etc (and least we forget Ruby) Is very painless and easy.

There is no real reason that Ruby can not also support native com
interfaces. A really elegant design would take some discussion to get right,
but it's far from rocket science.

> 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.

Yes, but it's not as nice as ruby.  And you can't dynamicaly create classes,
methods at runtime.  COM with ruby has all the fun of ruby and the
advantages of com.

> > 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.

You could then also argue that you should never get a specialist to do
anything.  Same argument. I was pointing out that I think MSVC is the best
way for the windows build because it is the standard.  And there are some
pretty good reasons why it has become that.

> 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.

The my OS is better than your OS thing is a pointless waste of bandwidth. If
you really want to run on windows, and it's not just a quick one off then
running native is best.  Otherwise it's kinda like putting an outboard on a
speed boat, sure you'll get there, but what do you loose in the process.
Because I haven't ever had reason to fork I can see no situation  that a
thread or process couldn't solve at least as well.  Lets not forget that
(IMHO) fork was really a workaround for not having threads.

Ralph