Re: [Orbit-python-list] ORBit-Python 0.2.0 released

[Jason T. <ta...@li...>]

> I believe the spec is important to a certain point, and beyond that, it's
> nonsense. The spec is there to guarantee portability between ORBs, but if
> you care very little about it, there's good reason to implement convenient
> mechanisms as options.

As you know, I'm not opposed to implementing extensions where they make
sense.  And the mapping spec certainly doesn't say implemenations can't
add their own extensions.  In fact, most of them do, I think.

The spec defines a base, so that all code written in compliance will be
portable between any compliant implementation.  So this is a good thing.
The trick is implementing extensions so they don't break the spec, and
that making sure programmers who use the extensions know they're
non-compliant.  This is one point that'll have to be worked out first.

> My personal opinion is that there should be a 'strict' mode and a 'o-p'
> mode, and implementing as far as it's possible both options in the
[...]
> to acheive the 'total' transparency feature. Python's dynamic nature is
> tied nicely to Any coercion, since you can really take advantage of the

Well, coercing Any is a little different than the transparent accessors.
With the transparent accessors you can use them, but you don't have to.
Your code works fine either way.  If you coerce _from_ Any to a Python
object (e.g. any myfoo() return the value itself instead of a CORBA.Any
object), then code that expects CORBA.Any will break. Coercing to Any
will work fine, mind you.

So I can see 3 different modes: strict, which forces you to comply with
the mapping spec; extended, which implements stuff like transparent
accessors, type coercion where it doesn't break the spec; and enhanced,
which implements all the fancy features we want.  (These names are up
for debate.)

"Extended" mode is a strict superset of "strict" mode, so that code
that's spec-compliant will work properly under Extended mode, but maybe
not vice versa.  "Enhanced" mode would contain stuff like coercion
_from_ CORBA.Any, where code that comes from another ORB _probably_
won't work without modification.  Extended mode would be the default.
The programmer can manually change the mode.  So if he wants to make
sure the code is easily portable to a different ORB, he'll turn on
"strict" mode.  ('course the interface to enable strict mode won't be
portable, but we can't have everything. :D)  If he wants to take
advantage of all the goodies, such as in your case, he'll enable
enhanced mode.

I'm mostly thinking aloud here.  Please everyone chime in with comments.
Once I organize my thoughts a bit better I'll consult the gurus on
Python do-sig and gather their input.

> flexibility types give us. And accessors.. well, do we really want to
> keep calling underscored methods? ;-)


Duncan Grisby gave some pretty compelling arguments in favor of using
the accessor functions in an email last August or September.  Basically
he said with:

   object.value = 1
   object.value = object.value + 2

By reading that code you'd assume object.value must be 3.  But it's
possible for the server implementation to override object._set_value (or
the __setattr__ method) to do something completely arbitrary.  It's also
possible for another client to modify object.value in between the first
two transparent method invocations.
object._set_value(object._get_value() + 2) is a little uglier but also a
little more explicit.  In some ways, it's more readable.  So it's not as
if the accessor methods are pointless in the face of the transparent
ones.  But I think the choice should be there for ORBit-Python because
nothing is sacrificed by providing it.

Jason.