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

# This mail seems not to be delivered...I resend.

[e-mail] (Tobin Baker) wrote:

> I think the stream-based model would be the one to follow.  I assume
> the object returned by _request() would subclass IO.

  Extending IO is natural way of type(or interface) thinking, but I think
the Ruby way is not type oriented but message oriented...
  And in practice, almost all of IO's method may be not used in this model.

  But I prefer interface oriented thinking because of easy for other person
to understand its outline, I don't strongly oppose to extend ID.


>   Then we could
> just define a to_s method for each class representing a CORBA type and
> call write(obj) to write a CORBA object to the request stream.  Then
> we call _invoke() on the request object, which returns an array of
> return values (or a single return value, and we're done.  Is there any
> reason to make the interface more complicated than this?
> 
> req = obj._request(:foo)
> req.write(arg)
> ret = req._invoke()

  I understand this to_s do marshaling and called by req.write().
  Then I think it is impossible to apply this generic framework.
  Please suppose:

    req.write(1)

  Is it marshalized as a short, long, ushort, or ...?

  It cannot be determined.
  At least integer specific methods(write_short, write_long, ...) are need.

  And if we define write_short() is needed, then to define more specific
methods for other primitive types is consistency and reasonable.


> >   // 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).
> >   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?
> 
> I don't have a good answer to this, although the C++ mapping specifies
> that if an IDL identifier clashes with a C++ keyword, it is prefixed
> with "_cxx_".  So maybe "Rb", "RB_", etc.?  Yuck.

  I agree...it is bad but possible.


> > | 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.
> 
> My implementation does just this.
> 
> >     //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...
> >
> 
> Well, what would you suggest then for an operation having one inout or
> out argument but no return value?  Obviously this is dubious IDL
> design, but it seems to be the most natural mapping.


> > | 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.
> > 
> 
> I've heard rumors that binding block parameters to variables defined
> in the enclosing scope may be going away in future releases of Ruby,
> so I'm a bit nervous about making this part of the spec, although I
> think it's quite slick :-)

  We now know the rumors is to be wrong;-)


>  Right now the mapping only sets the block
> parameters to the values of out arguments.  So you're suggesting that
> the block parameters should correspond exactly to the array that would
> be returned from the method (which would include out, inout, and
> return values)?

  I've think so. I think its purpose is to make scope for temporary variable.
  But you mainly aim to write substitution for out parameter more easy.

  I've think my situation is rare but I implement it because implementing
is easy.
  I think your purpose is better than me. I support your spec.

  But why inout parameter is not passed to argument block?
  It may be hard to understand...

  //IDL
    short do_it(out arg1, inout arg2, out arg3)

  #Ruby
    arg1, arg2, arg3 = nil
    ret, arg2 = do_it(arg2){|arg1, arg3|}

  #I prefer:
    arg1, arg2, arg3 = nil
    ret, = do_it(arg2){|arg1, arg2, arg3|}


> >   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.
> 
> I probably agree with you, it was largely the "coolness factor" that
> motivated this feature (borrowed from the Perl mapping, actually). 
> (And it does work, try it!)  I might just leave it in the
> implementation, since it doesn't get in anyone's way.  But it probably
> shouldn't be in the spec.

  Wmm...does Perl community values it?
  I've reread this and guess that I was misunderstand...


| Another feature emulates "call-by-reference" for inout parameters.  If a
| parameter to an operation invocation is a Ruby symbol, it is interpreted
| as an inout argument, provided the word "inout" is supplied as the last
| parameter to the invocation:
|
| //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

  I wonder what is the last argument inout?
  Is it a variable? Or typo of String?
  I thought it is variable correspond to `inout_arg' and used in complex
scheme.

  And I wonder how to change value of inout_arg.
  In definition of do_it(), the variable inout_arg cannot see if its 
Symbol is given...
# I don't know well about Symbol access of Ruby, I may overlook something.



  And I've forgotten one point of operation.
  Ruby cannot access to overrided method without using alias or super.
  So we should define full operation name.
  It is enough to alias simple name.

  //IDL
  interface I { void foo(); };

  //Ruby
  module I
    def foo()
    end
    alias I_foo foo
  end


> > | 5. Constants

> > //IDL
> > module Foo {
> > 	const float pi	= 3.14159265;
> > };
> > 
> > #Ruby
> > module Foo
> >   Pi = 3.14159265   # or it may be good that capitalize all characters...
> > end
> >
> 
> I'm not sure we should impose any more restrictions on naming than
> Ruby itself.

  Okey. We change case of only the first character.

  for constant:
    foobar -> Foobar
    FOOBAR -> FOOBAR
    fooBar -> FooBar

  for operation
    Foobar -> foobar
    FOOBAR -> fOOBAR
    FooBar -> fooBar