Issue 4040: New PSS Issue: Is the PSDL Grammar Too Complicated? (pss-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: When examining the PSDL grammar in the Persistent State Service, orbos/99-07-07, I came too the conclusion that it is over-specified. Looking through the IDL grammar, great care is taken to avoid overexpansion of the declarator productions. In particular, semantic rules are employed to restrict the use of scoped names (acting as types) in those situations where a particular use may be invalid. These rules could be applied in the same way to the declarator syntax for state members. Thus, there is no need to restrict the grammar to "abstract storagetype" types for declarators; any scoped name should work as elsewhere. Certainly, however, there should be semantic rules that only abstract storagetype types may be used in an abstract storagetype definition. Resolution: rejected Revised Text: Actions taken: November 14, 2000: received issue May 13, 2002: closed issue Discussion: This looks like a misreading of the specification: state members are not restricted to be abstract storagetype reference -- they can be pretty much any IDL type. See 3.2.5.2 "Abstract Storagetype State Members". End of Annotations:===== rom: thomas.s.hawker@mail.sprint.com X-OpenMail-Hops: 1 Date: Tue, 14 Nov 2000 14:08:47 -0600 Message-Id: Subject: New PSS Issue: Interface Inheritance MIME-Version: 1.0 TO: issues@omg.org Content-Type: multipart/mixed; boundary="openmail-part-34fae3e2-00000001" X-UIDL: \5f!!HE'!!:%e!!`"7e9 In the PSS specification (orbos/99-07-07), no provision is made for [abstract] storagetypes or [abstract] storagehomes to inherit from interface definitions. It appears this is an oversight as the omission does not seem reasonable. I have found cases in which a home would expose the same interface as a storage object, where the home subsequently delegates to a specific object however selected. Interfaces are a perfect mechanism whereby the operational signatures could be standardized, thus eliminating potential errors caused by changing one but not the other. Since storage objects are assumed to exhibit only local interface behavior, it would not matter whether the inheritance was from a local or remote interface definition. This could be accomplished using a supports clause in the inheritance specification similar to that of valuetypes. Tom Hawker Iconixx Incorporated Date: Tue, 21 Nov 2000 16:25:04 -0600 From: Tom Hawker Organization: Iconixx X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: pss-ftf@omg.org Subject: Issue 4039: additional thoughts Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^-3e9^l+e9&\j!!pYPe9 Another reason for interfaces is the multiple-inheritance abstraction they provide. Behavior can be abstracted into small, well-defined groups of related operations that can be combined as needed. This allows for the construction of complex hierarchies of objects, where the interfaces provide the behavior specification that are welded to the objects as implementation classes. Common behavior that must appear in multiple disjoint sections of the hierarchy (separated because of other lineage constraints) then have a single specification. In my own work writing database abstraction layers, this feature would have allowed major simplificiations in the overall object and manager [storagetype and storagehome] hierarchies. Tom Hawker, Iconixx thawker@iconixx.com