[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [sca-c-cpp] NEW ISSUE: Should the C++ SCA spec define annotations
TARGET: C++ C&I Specification DESCRIPTION: Should the C++ spec define annotations for marking up source code with SCA service information? C++ does not natively define an annotation format or behavior, so annotations must be defined as a language extension that is both compatible with standard C++, and presumably that would be parseable by an SCA defined parser. If the spec should define an annotation system for C++, we also need to define conformance guidelines for how those annotations will be used. (i.e., does the runtime need to parse the C++ in order to extract that information? Are annotations purely a design-time tool that allows code generation of SCDL files? should annotations result in code that is compiled into the library, that the runtime could query in order to extract a description of the service). PROPOSAL: There seem to be three primary approaches that we could take towards annotations, each with their associated implications. 1) Annotations are not defined by the spec. The SCA runtime would rely solely on the SCDL files in order to describe a service, and would not make any attempts to parse the source files at runtime. This will require that some information to be duplicated between the source code and the SCDL files that describe the source. The SCA spec would not attempt to define a mechanism for generating SCDL files from the source. It would leave it up to individual vendors to define their own mechanism, which could be through the use of annotations, or could be through some other proprietary mechanism. Portability would be maintained at runtime in that each runtime would be expected to consume SCDL files to retrieve description information, and should be independent of whether the SCDL was written by hand or generated from the source. This has the benefit of removing the need to define an annotation system in C++. Individual vendors would be free to define (or not define) they're own schemes for creating SCDL for C++ code. Those schemes could be annotation based, or could be provided by some other mechanism. 2) Annotations are a design-time tool to allow for generating SCDL files. As in (1), the SCA runtime would still rely solely on SCDL files in order to describe the service; however the specification would also define a mechanism for marking up code so that the SCDL files could be generated from the source. This is relatively close to what the current system supports, however it would clarify the role of annotations in the SCA runtime, and precedence rules for when information is defined in both the SCDL and in annotations (the canonical information would need to be in SCDL, annotations would not affect runtime behavior). This has the same benefit as (1) in regard to defining where canonical information is stored at runtime, in the SCDL files. If this was the approach we decided to pursue, would annotation support be required of a conforming implementation, or would this be a case where annotations are still optional, however if annotations are defined, they must follow this convention? Since this isn't an issue for the runtime (it will still reference SCDL), who would the conformance statements apply to? Is there a conformance target for tools vendors (which could be independent of the runtime vendors?). 3) Annotations are a runtime tool, allowing for programmatic introspection (and possibly design-time introspection as well). This is probably the most complex solution; however it would also provide functionality that's closest to what's being provided by Java's annotations. Under this mechanism, we would define an annotation system in C++ that would allow us to introspect the class at runtime in order to derive information. On a cursory review, there are two forms this could take. One would be to implement annotations through a macro-based system that would allow us to insert methods that would provide meta-data about a service into the service itself. Since C++ does not provide basic introspection for classes (such as what methods a class provides), we would have to go beyond the basic annotations that Java supports, and also define mechanisms for defining methods and their arguments through the annotations system as well. This could quickly result in us needing to define both the method and a macro with meta-information about the method for each method in the class. This seems like its going well beyond what the language would normally support, and is probably on the level of supporting dependency-injection, which we've implied is beyond the scope of what we want to tackle in the spec at this point. A second approach would be to generate a wrapper class around the user's class that would provide the meta-information. The runtime could then query this code-generated class at runtime in order to extract information. This would require annotations similar to what's required in (2). I'm not sure this would provide any benefit over parsing the SCDL file to retrieve this information (as in 2), and would mandate more about the runtime implementation than in (2). There may be further options for how we could achieve (3) that would eliminate some of the drawbacks outlined here. On a first pass, (2) seems like it may be the safest choice. This would maintain most of the compatibility with what was defined in OSOA 1.0, however it would also clarify the role of annotations, which should make writing conformance guidelines cleaner (and easier for vendors to implement). (1) however is also very tempting, as it would greatly simplify the spec (eliminating all discussion of annotations), and would provide vendors more flexibility in how they want to generated SCDL from source. Assuming we make supporting annotations optional, I believe (1) becomes a degenerate case of (2), as a complying vendor could opt out of supporting annotations, and could still provide an alternative mechanism for generating SCDL. A fourth option might be to go with (1) for the main specification, however to also provide a supplementary specification that defines conformance for a tool vendor to generate SCDL from source code. This could even be a non-normative document that just provides a recommended annotation format. Thanks. David. -- David Haney -- Chief Architect, Hydra Products -- Rogue Wave Software -- http://www.roguewave.com/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]