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

[Thomas B. Passin]

> uche.ogbuji@fourthought.com writes:
>>  > Note that I don't like the idea of the Python binding officially
supporting
>>  > two approaches, i.e. "node.parent" _and_ "node.get_parent()".  I think
it's
>>  > great for implementations to provide alternatives, but the binding
should
>>  > require one unequivocally.
>>
>>   I think the "right" way would be for someone to look at the CORBA
>> mapping the DO-SIG put together and follow that strictly; I think it's
>> pretty much through the OMG process.  I've not been following that as
>> closely as I'd like due to time constraints.

>Unfortunately, there is no specification for CORBA attributes in the do-sig
>Python binding.  I don't recall any discussion on the topic as long as I've
>followed that list, but I can't imagine it is an easy topic, especially
when
>you consider that Python ORBs often already need to hijack __[g/s]etattr__
for
>ORB run-time magic, marshalling, and all that.  The seemingly obvious
approach
>of "CORBA attributes == Python attributes" could lead to a nightmare for
>Python/CORBA users, considering the delicacy of __[g/s]etattr__, especially
in
>the presence of inheritance.
>--
>Uche Ogbuji

I'd like to remind everyone in this discussion that it is desirable for any
Python-DOM bindings to be obtained in a "regular" way - one that can be
programatically generated from the basic definitions.  To quote from the DOM
standard:

"As stated earlier, all object definitions are specified in XML. The Java
bindings, OMG IDL bindings, and ECMA Script bindings are all generated
automatically from the XML source code.

This is possible because the information specified in XML is a superset of
what these other syntax need. This is a general observation, and the same
kind of technique can be applied to many other areas: given rich structure,
rich processing and conversion are possible. For Java and OMG IDL, it is
basically just a matter of renaming syntactic keywords; for ECMA Script, the
process is somewhat more involved."

Python bindings should follow this principle.  This means that there should
not be different ways of naming different parts of the binding - so it would
either be spam.parent or spam.getParent() EVERYWHERE there are similar
calls - pick one style or the other.  If there are exceptions, it will be
hard or impossible to do programmatic generation of the bindings.  I'm
getting the sense that the tide is running on the side of spam.getParent().

Regards,

Tom Passin