From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-15T07:48:39+09:00
Subject: Re: Ruby and windows.

------=_Part_59206_33266993.1147646916334
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I wonder if you could write a utility that would parse a Ruby class and tur=
n
it into C code that you could compile down to a COM object. (Not the actual
Ruby code, just the methods and arguments, giving you the IDL and the COM
interface.) But then you'd need to shoehorn a Ruby interpreter into your CO=
M
container to run the objects. Hmmm.....

Might be better off with a SOA approach, depending on what you're trying to
do :-)

On 5/14/06, Tim Uckun <timuckun@gmail.com> wrote:
>
> My main goal in writing a COM object in Ruby is to be able call ruby
> code from VB and to replace VB COM objects with ruby COM objects. Ruby
> is a much more capably language then VB so I would like to use it
> instead.
>
> On 5/15/06, Francis Cianfrocca <garbagecat10@gmail.com> wrote:
> > >>>It would be really, really nice once the Ruby interpreter is thread
> safe
> > :)
> > Just by way of clarification, are you referring to the fact that Ruby
> > doesn't share synchronization primitives with the native platform? I've
> > given that some thought recently and it may be possible to accomplish
> with a
> > patch to Ruby's thread.rb. What's the point of it, however? Are you
> trying
> > to make it so a container can spin multiple COM threads and each thread
> can
> > access Ruby objects without any cooperation from Ruby's interpreter?
> >
> > More broadly (and I'm asking this out of curiosity, not tendentiously):
> > what's the point of being able to write a DLL in Ruby? Are people
> looking
> > for the ability to write CLR programs that include components written i=
n
> a
> > variety of different languages? And is there some reason to do this
> apart
> > from retaining compatibility with already-written stuff? If you did
> this,
> > how much of Ruby's metaprogramming would you have to give up, in order
> to
> > get a statically-enforceably contract that could be expressed as a COM
> > interface? I can imagine a more loosely-coupled way of achieving the
> same
> > thing.
> >
> > Sorry I'm not really contributing anything but more questions with this
> > post, but I'm trying to understand the questions that have already been
> > posed.
> >
> > On 5/14/06, John Lam <drjflam@gmail.com> wrote:
> > >
> > > In principle, this isn't hard to make happen. I could imagine a
> > > universal delegator approach where you cruft up a generic
> > > implementation of IDispatch and use Ruby's reflection capabilities to
> > > find methods to call. The only wierd stuff that you might have to
> > > worry about is mapping named parameters and marshaling SAFEARRAYS.
> > >
> > > The tougher thing is dealing with threading / apartment model
> > > compatibility. You could probably only make the STA threading model
> > > work for the generic case of a single STA in a process due to Ruby no=
t
> > > being thread safe.
> > >
> > > In RubyCLR I have to worry about the case where multiple STA threads
> > > attempt to call into Ruby - my proxies have to disallow the method
> > > call and raise a CLR exception.
> > >
> > > It would be really, really nice once the Ruby interpreter is thread
> safe
> > > :)
> > >
> > > -John
> > > http://www.iunknown.com
> > >
> > >
> >
> >
>

------=_Part_59206_33266993.1147646916334--