Michael Neumann <neumann / s-direktnet.de> wrote in message news:<3l_Y6.3692$Mq.409673 / e420r-sjo3.usenetserver.com>...
> 
> Perhaps I am missing something but why not use a InOut class:
> 
> class InOut
>   attr_accessor :value
>   def initialize(value=nil)
>     @value = value
>   end
> end
> 
> # generate n InOut objects
> def InOutFac(n)
>   (1..n).collect {InOut.new}
> end
> 
> # "declare" b and c
> b, c = InOutFac(2)
> 
> c.value = 22
> 
> f(a, b, c, d)
> 
> But probably that's not what you want. 
> 
> Regards,
> 
>   Michael

It seems to me that holder classes such as what you describe are
mainly necessary for the IDL-Java mapping.  C++ has return
by-reference, and Ruby can return an array, but Java is at a double
disadvantage, since it has neither return-by-reference nor multiple
return values--hence the need for holder classes.  But I see little
need to introduce this inconvenience into the Ruby mapping.

As I see it I basically have three alternatives:

1. Use holder classes like the IDL-Java mapping to make CORBA calls
from Ruby look as much as possible like the IDL declaration, but add
the extra inconvenience of dealing with wrapper classes.

2. Use something "magical" like my first or second proposals to
preserve both IDL semantics and language transparency.

3. Bite the bullet and use a convention like that recommended in the
Python mapping spec, which is perhaps more natural for the target
language but makes CORBA calls from Ruby look nothing like their IDL
declarations.

Of course, IDL was designed in the first place to look like C++, which
explains the use of return-by-reference rather than returned tuples to
simulate multiple return values.  So maybe the real question is, why
force Ruby to look like C++?  The most natural way in Ruby to return
multiple values from a method is obviously to return a list.  This is
how both the Perl and Python mappings treat out parameters.  Inout
parameters, however, are a different story.  The Perl mapping treats
them fairly naturally (as parameters to the method call) but both the
Python convention and the block-parameters trick force the programmer
to write inout parameters twice, once on each side of the assignment. 
As another post pointed out, this seems unnecessarily awkward.  It
therefore seems to me that my first proposal may not be as bad as I
had thought.  Having to put a colon in front of each inout parameter
is no worse, I think, than having to put a backslash in front of each
parameter (as in the Perl mapping).  And the fact that the caller is
forced to pass its context explicitly is perhaps not such a bad thing,
as another poster pointed out.  It shows that the caller is aware that
the method it's calling may alter any aspect of its environment.  I
think what I might do is include all of these possibilities in the
initial release, perhaps with some configure options to choose between
them.  User feedback is probably my best guide in these matters.  And
by the way, Matz, any thoughts on the caller_binding() proposal?