[ruby-talk:18899] Re: Dynamic ORBit bindings for Ruby

Hi,

From: [e-mail] (Tobin Baker)
Subject: [ruby-talk:18846] Dynamic ORBit bindings for Ruby
Date: Tue, 31 Jul 2001 07:52:16 +0900

> Purely coincidentally at almost the same time that Dai announced
> server-side support for Ruby, I've just finished the alpha release of
> my own ORBit bindings for Ruby.  Only the client-side bindings are
> included in this release, but server-side bindings are being debugged
> and should be ready in a few weeks.  All basic and user-defined IDL
> types are supported, including TypeCode and Any.  Most of the standard
> ORB and CORBA::Object operations are supported as well.  The DII is
> not supported since it is really unnecessary given the dynamic nature
> of both Ruby and these bindings.

I read the README of Dynamic-ORBit with great interest.  I am
interested in partially because I want to use CORBA with Ruby,
someday.  But mostly, my motivation is to pick up some idea to
improve my Ruby IDL mapping.  But I am not working on CORBA.

I am developing the rbXPCOM --- XPCOM Ruby language binding.

   <prug>http://rbxpcom.mozdev.org</prug>

XPCOM is an acronym of Cross Platform COM (Component Object
Model) developed and used by the Mozilla project.  It uses a
modified version of OMG IDL to define interface of components
(They call it xpidl).  I see there are some design issues shared
between Ruby CORBA effort and my project.

I would like to cooperate to create better language mapping for
Ruby and idl like interface.  Just reading your README already
made me rethink the way I map idl interface to Ruby module.
Maybe I will talk about this later.

For now, I would like to share my experience to "constant" and
"out parameter".

 CONSTANT
----------

from your README
> For at least two reasons, IDL constants are *not* mapped to Ruby
> constants.  In the first place, as we all know, Ruby "constants" are not
> really constant.  This is at variance with the "immutable" semantics
> implicit in IDL.  In the second place, Ruby constants must begin with
> a capital letter.  This is clearly an unreasonable requirement to place
> on CORBA implementors who write their IDL with other languages in mind.

The first argument is also applied to all Ruby programs.  I
guess many Ruby programmers can live it.  For the second
problem, my solution is simply upcase the first letter if it is
lower case.

> Therefore I implement constants as methods returning the value of the
> constant.  E.g.,
> //IDL
> module Foo {
> 	const float pi	= 3.14159265;
> };
>
> #Ruby
> module Foo
>  def pi
>    3.14159265
>  end
> end

I actually tried this idea in version 0.0.1 of rbXPCOM.  I
discarded, though.  Due to different scoping rules, it is more
confusing than helpful, IMHO.

module Foo
  Pi = 3.14159265
  def pi
    3.14159265
  end
end

class Bar
  include Foo
  p Pi
  p pi    # error
  def Bar.bar
    p Pi
    p pi  # error
  end
end

And, if the initial letter of a idl constant is just happen to be
upper case, you have another problem.

module Foo
  def Consant; 2 ; end
end

Foo::Constant     #=> NameError: uninitialized constant Constant at Foo

Above all, Ruby programmer will upset if Foo.constants returns [].


 OUT PARAMETER
---------------

from README
> //IDL
> interface Foo {
> 	long do_it(in long in_arg, out long out_arg, inout long
>		inout_arg);
> };
>
> #Ruby
> #somehow get reference myFoo to Foo object
> ret_val, out_arg, inout_arg_ret = myFoo.do_it(in_arg, inout_arg_par)

I just looked the testcase code and gathered that you do not
pack the returned value to an array if there is only one value
to return.  Is it correct?  If so, rbXPCOM uses exactly same
mapping.

You have two experimental mappings to simulate call-by-reference
semantics.  I am interested in how well they will turn out.  It
seems they both suffer the disadvantage of requiring 'variables
declaration', though.

From some coding experience with Mozilla's components, I learned
following things (at least for Mozilla's codebase).

  * There are few method that actually return useful multiple values.
    (Many methods return array or string and its size.  But the
    size is redundant as Ruby object already know its size.)

  * Use of inout is rather rare.

So, I decided I do not need elaborate mapping to deal with the
call-by-reference thing, at least for now.  I just sticked to
what Python CORBA mapping is using for years.

Best Regards,
Kenichi Komiya.