> Does the Ice team claim any advantages to their Python bindings to
> CORBA over omniORBpy (The one I am currently using). [...]
> But I was wondering if there are any dynamic language
> oriented improvements in ICE bindings?
The Ice Python mapping is simpler than the CORBA one because Ice has
a simpler object model with fewer data types. So, Ice avoids the
complexities caused by things such as type Any, TypeCodes, value types,
bounded sequences, arrays, unions, the fixed type, unsigned versus
signed types, and wide versus narrow characters and strings. Other than
that, the Ice Python mapping is quite similar to the CORBA one, mainly
because, for most language mapping issues, the design problems and (sensible)
solutions are the same.
As far as dynamic improvements are concerned, Ice for Python is a bit more
flexible than omniORBpy. As with omniORBpy, you can put interface definitions
through a compiler to generate stubs and skeletons but, in addition, you can
also use Ice for Python without precompiling the interface definitions and,
instead, load them at run time. As an example, assume you have a
definition as follows:
module M {
enum Color { red, green, blue };
};
Instead of compiling the definition, you can write:
Ice.loadSlice("Color.ice")
import M
print "My favourite color is ", M.Color.blue
Which approach (precompiled or dynamically loaded) you use depends
on the specifics of your application. Dynamically loaded definitions
are useful especially for things such as test harnesses and short throw-away
programs, because not having to compile the definitions first reduces
complexity
and makes the application more compact (because it doesn't depend on a bunch
of additional files that would be created by pre-compiling the definitions).
Of course, the price you pay is a (small) delay during start-up because the
code is generated at run time rather than compile time.
Cheers,
Michi.
--
Michi Henning Ph: +61 4 1118-2700
ZeroC, Inc. http://www.zeroc.com
--
http://mail.python.org/mailman/listinfo/python-list
