[ruby-talk:20421] Re: CORBA Ruby mapping

> On a related note, I've been thinking for a while about (but haven't
> had any time to work on) an idea that would take portability still
> further.  It would achieve similar portability to the above approach,
> but would actually extend it to proprietary ORB's for which the
> internal API is unavailable.  Basically it uses the DII, TypeCode, and
> DynAny interfaces to construct a universal CORBA client (and possibly
> a limited CORBA server using the DSI).  All marshaling/unmarshaling,
> method dispatch, and other details which are traditionally accessible
> only through the ORB's internal API can, at least theoretically, be
> implemented purely in terms of these standard CORBA interfaces.  I

   I think it is the other style of portability defined in the IDL to Java specification.

   In the chapter "1.21.5.1 Stub/SkeletonArchitecture" of the specification(you can get it
  from http://www.omg.org/cgi-bin/doc?formal/01-06-06 ), there are two portable stub code,
  Stream-based and DII-based. I like the Stream-based code mainly because of its ease.
  But the DII-based code is superior than Stream-based one in point of flexibility.


> The way I think our projects could fit
> together is something like this.  We first define the Ruby-IDL
> mapping.  Then we (or you) define the standard Ruby client/server
> interface.  Then we (or I) implement this interface purely in terms of
> the IDL C++ mapping.  Now we have an API which can have either an
> ORB-specific implementation (like your ORBit wrapper) for efficiency,
> or a portable implementation (possibly at some loss of efficiency,
> depending on how well the DynAny and DII interfaces are implemented). 
> I think this combination would put Ruby way ahead of other scripting
> languages.  What are your thoughts (and anyone else's)?

  If I correctly understand your plan, I think our schemes are compensate together ;-)
  Althoug I don't know how to define CORBA in other script languages, I think Ruby mapping
becomes more dynamic than and at least same structured to Java.
  As you say, at first we should define IDL-Ruby mapping.



  from [ruby-talk:20247]
  
> Dai <[e-mail]> wrote in message news:<[e-mail]>...

> >   following is my comment on Tobin's README.
> > 
> > ---
> > > 1. Modules

> >   I also think IDL's module or constant name should be capitalized in Ruby.
> >   But there are one problem. If its name conflicts with language predefined name,
> > other language bindings prefixes it with `_' while mapping from IDL name.
> > As you know, Ruby's constant cannot start with a underscore.
> 
> I'm inclined to think now that module names should have the first
> letter capitalized in the Ruby mapping.  This shouldn't cause name
> conflicts since IDL won't let you use two identifiers in the same
> scope that differ only in case.  Same goes for constants--my approach
> (creating "constant" methods) was just too confusing.

  But conflict occures between IDL's name and Ruby's one.
  for example,

  // IDL
  module String {
    ...
  };

  # ruby
  module String  # error!
    ...
  end

  What should this identifier mapped to?
  Although Java mapping specify it is mapped to "_String", but first underscore character
is not allowed as Ruby constant(or classname).

  FYI, IDL identifiers is defined as
|    An identifier is an arbitrarily long sequence of ASCII alphabetic, digit, and
|   underscore("_") characters. The first character must be an ASCII alphabetic character.

  And Ruby's constant is the same except that it should start with captal letter.
  I currently ignore this issue, because any good idea comes into my mind.
  Can anyone solve it?


> > > 2. Interfaces
> > 
> > IDL interfaces are also mapped to Ruby modules.
> > > Each Ruby module
> > > corresponding to an IDL interface includes the base module CORBA::Object,
> > > which declares all the methods found in the IDL CORBA::Object interface,
> > > prefixed with an underscore, along with an additional method, repo_id,
> > > which returns the interface's Repository ID.
> > 
> >   In other language binding, a method like repo_id() defined in its Portability
> > Specification. In Java, the _ids() method id defined in the class of
> > org.omg.CORBA.portable.ObjectImpl.
> > 
> > 
> > > myBaz = CORBA::ORBit::Stub.new()
> > > myBaz.extend(Foo::Bar::Baz)
> > 
> >   I prefer to use Stub's _narrow() method for it.
> 
> Maybe you misunderstood--this code was only for purposes of
> illustration (stubs are never explicitly instantiated).  This is just
> Ruby pseudocode for the C implementation.  Clients are expected to use
> _narrow() in my mapping.

  I see.
  To implement _narrow() method is responsible for each ORB vender.



| 3. Operations
| 
| IDL operations are mapped to Ruby method definitions.  As a rule,
| in arguments are passed as ordinary parameters, return values and
| out arguments are returned as a single array, and inout arguments are
| passed in like in parameters and returned like out parameters, with no
| "pass-by-reference" semantics involved.  E.g.,

| //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 agree.
  But I suspect if there are only one returned value, it is useful that the value itself is
returned.

    //IDL
    interface Foo {
    	long do_it(in long in_arg);
    	void do_it2(in long in_arg, inout inout_arg);
    };
    #Ruby
    ret_val1 = myFoo.do_it(in_arg)
    ret_val2 = myFoo.do_it2(in_arg, inout_arg)

  I think invoking do_it() is reasonable but do_it2() is a bit confusable...



| Specifically, if
| a block is supplied with a CORBA operation invocation, the block will be
| executed with all block parameters set to the values of corresponding out
| arguments returned by the invocation.  Since Ruby binds block parameters
| to any local variables with the same name defined in the enclosing scope
| of the block, this can be used to simulate "call-by-reference".  E.g.,
|
|   arg1, arg2, arg3 = nil
|   do_it() {|arg1, arg2, arg3|}
|   p arg1, arg2, arg3 #prints 1, 2, 3

  It is interesting.
  I also think if block is given to remote method invocation, then returned array is
normally passed to block argument. This rule is very fit to Ruby.
  And as you show, if the block argument is already defined in outer scope, they are
automatically set.
  I think we say that you can give an iteretor to any remote method invocation and that
substitution to outer variable is a tips not a rule.


| //IDL
| interface Foo {
| 	void do_it(inout inout_arg);
| };
| //implementation adds 1 to inout_arg
| 
| #Ruby
| #somehow get reference myFoo to Foo object
| inout_arg = 10
| do_it(:inout_arg, inout)
| p inout_arg #prints 11

  It seem to be overspec.
  I think inout parameter is rarely used and eventually confusable.
  So it is unnecessary to make it easy to write.


| 4. Attributes
|
| IDL attributes are mapped to Ruby methods of the same name.  For ordinary
| attributes, a "getter/setter" pair of methods is created; for readonly
| methods, only a "getter" method is created.  These follow the ordinary
| Ruby naming conventions for attributes, e.g.,

  I think so.


| 5. Constants

| 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.
| Therefore I implement constants as methods returning the value of the
| constant.  E.g.,

  Although I agree the first problem, I think it is better that IDL constant is mapped
to Ruby constatnt. Using method is not to solve this problem because Ruby allows
programmer to redefine any method.

  And I don't mind the second problem because there are same restrict in module, interface,
method(its first letter must be lower case letter), and so on.


//IDL
module Foo {
	const float pi	= 3.14159265;
};

#Ruby
module Foo
  Pi = 3.14159265   # or it may be good that capitalize all characters...
end


  following sections are on the next time...

| 6. Exceptions
| 7. Structs
| 8. Unions
| 9. Sequences
| 10. Arrays
| 11. Enumerations
| 12. Typedefs
| 13. Any
| 14. TypeCodes
| 15. The Client-Side Mapping for the ORB Pseudo-Object