Issue 3188:  PSS FTF issue: Restrictions on PSDL concrete types                                                                                                                                                     (pss-ftf)
Source: ZeroC (Mr. Bernard Normier, bernard@zeroc.com)
Nature: Uncategorized Issue
Severity: 
Summary: A number of restrictions on concrete PSDL types have the effect 
to force PSS users to use abstract types. For example keys can 
only be defined on abstract storage homes, so in order to define 
a key (and the implied finder operations), a PSS user needs 
to define an abstract storage type and an abstract storage home.

Accessing storage objects and storage homes through abstract
storage types and homes provides flexibility (with some
PSS implementations this allows you to switch from one PSS
implementation to another one without recompiling or relinking
the code that uses the storage objects) but is also more complex
since it doubles the number of PSDL constructs you need.

For applications that don't need this flexibility, abstract
types are overkill -- and make PSDL look quite complex to 
understand and use. I propose to review the restrictions 
on concrete types to make them usable without abstract types.

Resolution: accepted
Revised Text: - [concrete] storage homes can define keys and factory operations.
- [concrete] storage types resp. storage homes can have operations (like abstract storage
types resp abstract storage homes)
- to keep the grammar LALR(1) we move reference representation and primary key
declarations outside the body of the type, like in the old Inprise/Persistence submission.
For example:
storagetype Account
ref(accno)
{
state long accno;
state float balance;
};
storagehome Bank of Account
primary key accno
{
key accno;
factory create(accno, balance);
};
Revised Text:
See http://cgi.omg.org/pub/pss_ftf/proposals.pdf (color BLUE)
Actions taken:
January 7, 2000: received issue
October 3, 2001: closed issue
Discussion: 

End of Annotations:=====
Date: Fri, 07 Jan 2000 14:45:43 -0500
From: Bernard Normier <bernard.normier@iona.com>
Organization: IONA Technologies
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: issues@omg.org
Subject: PSS FTF issue: Restrictions on PSDL concrete types
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: /hAe9ZL/e9=ZS!!m0*e9

A number of restrictions on concrete PSDL types have the effect 
to force PSS users to use abstract types. For example keys can 
only be defined on abstract storage homes, so in order to define 
a key (and the implied finder operations), a PSS user needs 
to define an abstract storage type and an abstract storage home.

Accessing storage objects and storage homes through abstract
storage types and homes provides flexibility (with some
PSS implementations this allows you to switch from one PSS
implementation to another one without recompiling or relinking
the code that uses the storage objects) but is also more complex
since it doubles the number of PSDL constructs you need.

For applications that don't need this flexibility, abstract
types are overkill -- and make PSDL look quite complex to 
understand and use. I propose to review the restrictions 
on concrete types to make them usable without abstract types.

Proposal
--------
- [concrete] storage homes can define keys and factory operations.
- [concrete] storage types resp. storage homes can have 
  operations (like abstract storage types resp abstract
  storage homes)
- to keep the grammar LALR(1) we move reference representation
  and primary key declarations outside the body of the type, 
  like in the old Inprise/Persistence submission. For example:
  
  storagetype Account 
       ref(accno)
  {
     state long accno;
     state float balance;
  };

  storagehome Bank of Account
       primary key accno
  {
     key accno;
     factory create(accno, balance);
  };


Regards,

Bernard