Difference between revisions of "Documentation/DevGuide/WritingUNO/Grouping Definitions in Modules"
OOoWikiBot (Talk | contribs) m (Robot: Automated text replacement (-Category:Documentation/Developers Guide/Professional UNO +Category:Documentation/Developers Guide/Writing UNO)) |
m |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 6: | Line 6: | ||
|NextPage=Documentation/DevGuide/WritingUNO/Simple Types | |NextPage=Documentation/DevGuide/WritingUNO/Simple Types | ||
}} | }} | ||
| + | {{Documentation/DevGuideLanguages|Documentation/DevGuide/WritingUNO/{{SUBPAGENAME}}}} | ||
{{DISPLAYTITLE:Grouping Definitions in Modules}} | {{DISPLAYTITLE:Grouping Definitions in Modules}} | ||
To avoid name clashes and allow for a better API structure, UNOIDL supports naming scopes. The corresponding instruction is module: | To avoid name clashes and allow for a better API structure, UNOIDL supports naming scopes. The corresponding instruction is module: | ||
| − | < | + | <syntaxhighlight lang="idl"> |
module mymodule { | module mymodule { | ||
}; | }; | ||
| − | </ | + | </syntaxhighlight> |
Instructions are only known inside the module mymodule for every type defined within the pair of braces of this module <code>{}</code>. Within each module, the type identifiers are unique. This makes an UNOIDL module similar to a Java package or a C++ namespace. | Instructions are only known inside the module mymodule for every type defined within the pair of braces of this module <code>{}</code>. Within each module, the type identifiers are unique. This makes an UNOIDL module similar to a Java package or a C++ namespace. | ||
Modules may be nested. The following code shows the interface <code>XUnoUrlResolver</code> contained in the module bridge that is contained in the module star, which is in turn contained in the module sun of the module com. | Modules may be nested. The following code shows the interface <code>XUnoUrlResolver</code> contained in the module bridge that is contained in the module star, which is in turn contained in the module sun of the module com. | ||
| − | < | + | <syntaxhighlight lang="idl"> |
module com { module sun { module star { module bridge { | module com { module sun { module star { module bridge { | ||
// interface XUnoUrlResolver in module com::sun::star::bridge | // interface XUnoUrlResolver in module com::sun::star::bridge | ||
}; }; }; }; | }; }; }; }; | ||
| − | </ | + | </syntaxhighlight> |
| − | It is customary to write module names in lower case letters. Use your own module hierarchy for your IDL types. To contribute code to OpenOffice.org, use the <code>org::openoffice namespace or com::sun::star</code>. Discuss the name choice with the leader of the API project on [ | + | It is customary to write module names in lower case letters. Use your own module hierarchy for your IDL types. To contribute code to OpenOffice.org, use the <code>org::openoffice namespace or com::sun::star</code>. Discuss the name choice with the leader of the API project on [https://www.openoffice.org www.openoffice.org] to add to the latter modules. The <code>com::sun::star</code> namespace mirrors the historical roots of OpenOffice.org in StarOffice and will probably be kept for compatibility purposes. |
Types defined in UNOIDL modules have to be referenced using full-type or scoped names, that is, you must enter all modules your type is contained in and separate the modules by the scope operator <code>::</code>. For instance, to reference <code>XUnoUrlResolver</code> in another idl definition file, write <code>com::sun::star::bridge::XUnoUrlResolver</code>. | Types defined in UNOIDL modules have to be referenced using full-type or scoped names, that is, you must enter all modules your type is contained in and separate the modules by the scope operator <code>::</code>. For instance, to reference <code>XUnoUrlResolver</code> in another idl definition file, write <code>com::sun::star::bridge::XUnoUrlResolver</code>. | ||
| Line 26: | Line 27: | ||
Besides, modules have an advantage when it comes to generating language specific files. The tools ''cppumaker'' and ''javamaker'' automatically create subdirectories for every referenced module, if required. Headers and class definitions are kept in their own folders without any further effort. | Besides, modules have an advantage when it comes to generating language specific files. The tools ''cppumaker'' and ''javamaker'' automatically create subdirectories for every referenced module, if required. Headers and class definitions are kept in their own folders without any further effort. | ||
| − | One potential source of confusion is that UNOIDL and C++ use “<code>::</code>” to separate the individual identifiers within a name, whereas UNO itself (e.g., in methods like | + | One potential source of confusion is that UNOIDL and C++ use “<code>::</code>” to separate the individual identifiers within a name, whereas UNO itself (e.g., in methods like <idlm>com.sun.star.lang.XMultiComponentFactory:createInstanceWithContext</idlm>) and Java use “<code>.</code>”. |
{{PDL1}} | {{PDL1}} | ||
| − | [[Category:Documentation/ | + | [[Category:Documentation/Developer's Guide/Writing UNO Components]] |
Latest revision as of 16:14, 23 December 2020
To avoid name clashes and allow for a better API structure, UNOIDL supports naming scopes. The corresponding instruction is module:
module mymodule { };
Instructions are only known inside the module mymodule for every type defined within the pair of braces of this module {}. Within each module, the type identifiers are unique. This makes an UNOIDL module similar to a Java package or a C++ namespace.
Modules may be nested. The following code shows the interface XUnoUrlResolver contained in the module bridge that is contained in the module star, which is in turn contained in the module sun of the module com.
module com { module sun { module star { module bridge { // interface XUnoUrlResolver in module com::sun::star::bridge }; }; }; };
It is customary to write module names in lower case letters. Use your own module hierarchy for your IDL types. To contribute code to OpenOffice.org, use the org::openoffice namespace or com::sun::star. Discuss the name choice with the leader of the API project on www.openoffice.org to add to the latter modules. The com::sun::star namespace mirrors the historical roots of OpenOffice.org in StarOffice and will probably be kept for compatibility purposes.
Types defined in UNOIDL modules have to be referenced using full-type or scoped names, that is, you must enter all modules your type is contained in and separate the modules by the scope operator ::. For instance, to reference XUnoUrlResolver in another idl definition file, write com::sun::star::bridge::XUnoUrlResolver.
Besides, modules have an advantage when it comes to generating language specific files. The tools cppumaker and javamaker automatically create subdirectories for every referenced module, if required. Headers and class definitions are kept in their own folders without any further effort.
One potential source of confusion is that UNOIDL and C++ use “::” to separate the individual identifiers within a name, whereas UNO itself (e.g., in methods like createInstanceWithContext) and Java use “.”.
| Content on this page is licensed under the Public Documentation License (PDL). |
