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

[Ken MacLeod]

"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:

>  	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.

This sounds more like a "MAY" requirement than a "MUST" requirement.
Since Python, like several languages, supports accessor syntax it
seems logical to use it.

>    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.

I don't see how this is relevant.  CORBA is already calling them
attributes with the assumption that it's not state.  Python supports
the same.

>    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

Implementation of attributes that support encapsulation has been
discussed at length in this thread.

>    c) consistency across implementation languages
> 
>    Attribute access means methods/functions in almost all languages.

It's very possible that the reason for that is that those languages
don't support accessor syntax.  One of the biggest problems with
recent "language independent" architectures is that they all seem to
have been born out of or heavily influenced by C++ and it's draconian
approach to OOP.  The reason these architectures define support for
and often recommend accessor methods is because C++, the largest
influence of the architecture and it's most common client, doesn't
support anything else.

>    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.

Several Python modules support attribute exceptions besides
AttributeError.

> 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.

The bug in this case seems to be very subtle.  Clearly, the CORBA
specs recognize attributes and would seem to suggest using them as
easily as possible, yet it is common practice in primary and secondary
specs, and in discussions of them, to only reference languages (most
commonly C++ or Java) that don't support attribute access.  This
fosters and spreads the notion that all implementations _must_ use
method accessors whenever attributes are suggested.

-- 
  Ken MacLeod
  ken@bitsko.slc.ut.us