[DO-SIG] Re: [XML-SIG] foo.bar vs. foo.get_bar()

[Martin v. Loewis]

>   That doesn't sound good at all.  Let me take a quick look...
>   Ok, in the 2-Aug-1999 document from the OMG archive (I think that's
> current), at the top of page 17 (section 4.4):
> 
> 	"If an interface defines an attribute name, the attribute is
>          mapped into an operation _get_name, as defined  If the
>          attribute is not readonly, there is an additional operation
>          _set_name, as defined in chapter 3.11 of CORBA 2.2.  These
>          operations may raise exceptions, as defined by the CORBA
>          Components submission (orbos/99-04-16)."
> 
> (The weird ending of the first sentence is a correct quote.)
>   So, it looks like we should be writing node._get_parent().  *Really* 
> ugly, but if compliance is what matters, that's compliance.

Oops. That should be

 	If an interface defines an attribute name, the attribute is
        mapped into an operation _get_name, as defined in chapter
        3.11 of CORBA 2.2. If the attribute is not readonly, there is
        an additional operation _set_name.

(perhaps wording could be better). I'm not sure which part of it you
consider ugly, let me guess:

1. using accessor functions, instead of mapping to attributes. There
   is a number of reasons not to use attributes:

   a) Conformance to the Core. The referenced CORBA/Core section says

   #An attribute definition is logically equivalent to declaring a pair
   #of accessor functions; one to retrieve the value of the attribute
   #and one to set the value of the attribute.

   So even though the syntax says 'attribute', it is *not*
   'state'. Instead, the object implementation must ultimately deliver
   the value. On the server side, this means methods. Specifying how
   the __getattr__ of an implementation interworks with the ORB's
   own __getattr__ code is just not feasible.

   b) encapsulation

   Some people think that directly setting attributes is evil, you
   ought to have accessor methods. There is some value to that point,
   especially as setting the attribute leads to a round-trip (to the
   server), something that is not all that clear from

      foo.bar = 3

   c) consistency across implementation languages

   Attribute access means methods/functions in almost all languages.

   d) support for exceptions in attributes.

   With CORBA 3.0, you can say

   interface I{
     readonly attribute long foo raises(Bar);
   }

   when you write

     print bla.foo

   you may expect an AttributeError, but you normally don't expect a
   CORBA.UserException. With

     print bla._get_foo()

   this is more obvious.

2. Choice of the specific names.

   Again, this choice is suggested by the Core:

   # The attribute declarations are equivalent to the following
   # pseudo-specification fragment: ... 
   #          float _get_radius (); 
   #          void _set_radius (in float r);

   although it clearly says

   # The actual accessor function names are language-mapping specific.

   In C++ and Java, they use overloading, but we don't have
   overloading. Plain 'get_<x>' and 'set_<x>' is ruled out because
   it would create conflicts:

   interface I{
     readonly attribute long bla;
     void set_bla(in long newvalue, in Cred credentials);
   };

   The '_set_' and '_get_' prefixes don't create conflicts, since IDL
   identifiers must not start with underscores.

Since this is the first time this came up in a long time, I'd say that
either

a) attributes are rarely used, and don't happen in real life, or

b) users of the mappings get used to the API and don't consider it
   *really* ugly.

If you are still not satisfied: OMG will soon start collecting
issues. If you feel this is a bug in the spec, please let us know.

Regards,
Martin