From: senderista@... (Tobin Baker) Date: 2001-09-02T19:31:24+09:00 Subject: [ruby-talk:20696] Re: CORBA Ruby mapping Daisuke KANDA wrote in message news:<20010827.180422.893775648.dai@iij-mc.co.jp>... > 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. I think the stream-based model would be the one to follow. I assume the object returned by _request() would subclass IO. 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 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. > > > 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). > 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. > | 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 :-) 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)? > | //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. 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. > | 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. > I think I completely agree with you here. My initial mapping was a mistake. > //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. > following sections are on the next time...