Increasing UNO Ease of UseWhy must I improve myself The following lists all the changes made so far (on SRC680 CWS sb10 and sb14) to increase UNO ease of use: multiple-inheritance interface types with optional base types and extended arguments, single-interface–based services with constructors, and interface-based singletons. OverviewThe main theme of all the changes made is adding type safety: Multiple
inheritance has been added to UNO interface types, so that clients can now
access a complete UNO object (or at least a large part of it) through a single,
well-typed reference—no need to use That move made UNO interface types almost as expressive as UNOIDL service
descriptions. What was lacking were optional base interfaces and the richness
of service properties ( Single-Interface–Based ServicesBut service descriptions are not dropped, they are rather turned into a more precise, and more useful concept: A new style of UNO services, called single-interface–based services, written in the form
module someModule {
service SomeService: XSomeInterface {
ctor1( [in] long p1, [in] string p2)
raises (IllegalArgumentException);
ctor2([in] any... args);
};
};
are used to express services that are available at the global service
manager,
under a given name (
XComponentContext context = …;
XSomeInterface service = someModule.SomeService.ctor1(context, 10,
"Whatever");
instead of
XComponentContext context = …;
XSomeInterface service = (XSomeInterface.class) UnoRuntime.queryInterface(
XSomeInterface.class,
context.getServiceManager().createInstanceWithContextAndArguments(
"someModule.SomeService",
new Any[] { new Integer(10), "Whatever" },
context));
Interface-Based SingletonsThe same happens to UNOIDL singleton descriptions—they are turned into new-style interface-based singletons of the form
module someModule {
singleton SomeSingleton: XSomeInterface;
};
that can be used like
XComponentContext context = …;
XSomeInterface singleton =
someModule.SomeSingleton.get(context);
instead of the old
XComponentContext context = …;
XSomeInterface singleton = (XSomeInterface)
AnyConverter.toObject(
XSomeInterface.class,
context.getValueByName("/singletons/someModule.SomeSingleton"));
Optional Base InterfacesOptional base interfaces have been added to UNO interface types as a pure design tool (that is, they do not map to any constructs within the language bindings). The intention behind optional base interfaces is that in a scenario like
interface XSomeInterface {
/** semantic constraints for mandatory XBase1 */
interface XBase1;
/** semantic constraints for mandatory XBase2 */
interface XBase2;
/** semantic constraints for optional XBase3 */
[optional] interface XBase3;
};
interface XOtherInterface {
interface XSomeInterface;
interface XBase3;
};
Extended AttributesThe last missing piece is how to map the rich,
As a first step, attributes are extended with raises clauses, in the form of
interface XSomeInterface {
[attribute] long attr {
get raises (UnknownPropertyException);
set raises (IllegalArgumentException);
};
};
This allows to map To map
struct Option<T> {
boolean hasValue;
T value;
};
(or similar) can be used to encode the as an equivalent UNO interface type attribute Polymorphic struct types have not yet been added to UNO, they are scheduled for the next increment. However, some notes on how they will probably be implemented are given here already:
Once extended interface type attributes are fully available, there will
probably be less demand for
For implementors of such UNO objects, it would be helpful to find support in
the language bindings: The implementors will only code the getters and setters
of the various attributes, and helper classes will be available that add
That way, adding only the single wart of [TODO: The following lists only the changes made on SRC680 CWS sb10 to add multiple-inheritance interface types to UNO. It does not yet incorporate the additional changes made on SRC680 CWS sb14. Those changes will be documented here as soon as possible.] UNO Changes for Multiple-Inheritance Interface TypesChanges to Core UNOThe definition of interface types in UNO Type System (revision 1.4) changes to the following (with actual changes in red):
Function IndicesIn various places (binary UNO, URP, the C++ bridges), the concept of function indices is needed: a mapping between integers (i.e., function indices) and the members of an interface type. All those places use the same algorithm to construct these mappings, which is now described in the section “Function Indices” of UNO Type System. Changes to UNOIDLThe syntax for interface types in UNOIDL changes from interface_dcl: interfaceheader to interface_dcl: interfaceheader It is an error for an interface_dcl to have both a non-empty inheritance_spec and one or more interface_inheritance_decls. Then, there are four cases how the list of direct bases can be specified for an interface type in UNOIDL:
Module Changes to Binary UNOThe format of the binary type library (Binary specification of the type representation in the UNO typelibrary) already allowed to represent interface types with more than one base type (nSuperTypes in the header section). The low-level The interface-type–related UNO type description types in
The UNO interface type
Changes to The C++ Language BindingMultiple UNO interface inheritance maps naturally to multiple inheritance of C++ classes. The The implementation helper classes ( The framework for the various platform-specific C++–binary-UNO bridges
(
The bridges in Changes to The Java Language BindingMultiple UNO interface inheritance maps naturally to multiple Java interface inheritance. The Changes to The Python Language Binding[TODO: To be determined.] Changes to The CLI Language Binding[TODO: To be determined.] Changes to URPThe notion of method IDs in UNO Remote Protocol Version 1.0 Specification (revision 1.9) has been revised (in revision 1.10). First, “method ID” has been changed to “request ID,” to avoid confusion with the methods of interface types. Second, the request ID that corresponds to a given interface type member function is defined to be the function index the member function maps to. It is an error for the function index to be outside the range [0 … 216 − 1]. The binary-UNO– and Java–URP bridges in modules
TestsThere are new tests in Documentation[TODO: The Developer's Guide has to be updated.]
|
By any use of this Website, you agree to be bound by these Policies and Terms of Use
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.