I very much like Rel's support for selector invocations denoting values of system-defined types. For example INTEGER(-1) and BOOLEAN(TRUE) are equivalent to the literals -1 and TRUE, respectively. I also like the fact that such invocations can be nested, as in INTEGER(INTEGER(-1)) and so on, ad infinitum.
But the signature INTEGER(INTEGER) for an operator that has all the required properties of a selector, strongly suggests the existence of a possrep giving rise to that operator. That possrep would be named INTEGER, of course, and would have a single component. What might be the name of that component? Well, INTEGER seems the obvious choice, suggesting the following notional type definition:
TYPE INTEGER POSSREP INTEGER ( INTEGER INTEGER ) ;
which implies the existence of operator defined like this:
THE_INTEGER(INTEGER INTEGER) RETURNS INTEGER; RETURN INTEGER; END OPERATOR;
Of course the type definition and operator definition don't have to keep on repeating the name INTEGER in the way I've suggested, and in any case I'm not suggesting these imaginary definitions should appear anywhere. But I would like to be able to write THE_INTEGER(INTEGER(-1)), for example, and also, more importantly, to define a subtype of INTEGER such as this:
TYPE POSINT IS { INTEGER POSSREP POSINT ( INTEGER = THE_INTEGER(INTEGER) CONSTRAINT INTEGER > 0 } ;
That's because Tutorial D requires a nonempty <derived possrep def list> in subtype definitions (perhaps unfortunately).
Hugh
possreps for system-defined types
Re: possreps for system-defined types
I vaguely recall that there is some mention somewhere that the non-empty <derived possrep def list> requirement does not apply to subtypes of built-in types, with the result that I made the following legitimate:
TYPE POSINT IS { INTEGER CONSTRAINT INTEGER > 0 };
A bit of a caveat, though: Subtyping of built-in types is a feature that's not well-tested, so it may result in instability or poor performance. If you try it, make regular backups!![Smile :)](./images/smilies/icon_smile.gif)
TYPE POSINT IS { INTEGER CONSTRAINT INTEGER > 0 };
A bit of a caveat, though: Subtyping of built-in types is a feature that's not well-tested, so it may result in instability or poor performance. If you try it, make regular backups!
![Smile :)](./images/smilies/icon_smile.gif)
Re: possreps for system-defined types
A further thing to note:
If you implement a type like POSINT that is inherited from a built-in type, a backup generated of its database will have all literals where the type constraint is true changed to that type!
For example, the following definition:
TYPE POSINT IS { INTEGER CONSTRAINT INTEGER > 0 };
Will produce a backup that shows the sys.Catalog CreationSequence attribute values as POSINT(2), POSINT(4), etc.
Indeed, anywhere a positive INTEGER literal n appeared, it will be emitted as POSINT(n). That means if you wish to restore the database, you either need to move the TYPE POSINT ... definition to the top of the backup script so it's compiled before anything else, or manually change all POSINT(n) literals back to n.
If you implement a type like POSINT that is inherited from a built-in type, a backup generated of its database will have all literals where the type constraint is true changed to that type!
For example, the following definition:
TYPE POSINT IS { INTEGER CONSTRAINT INTEGER > 0 };
Will produce a backup that shows the sys.Catalog CreationSequence attribute values as POSINT(2), POSINT(4), etc.
Indeed, anywhere a positive INTEGER literal n appeared, it will be emitted as POSINT(n). That means if you wish to restore the database, you either need to move the TYPE POSINT ... definition to the top of the backup script so it's compiled before anything else, or manually change all POSINT(n) literals back to n.
-
- Posts: 124
- Joined: Sat May 24, 2008 4:49 pm
Re: possreps for system-defined types
Thanks, Dave. Yes, the IM extensions to Tutorial D allow INTEGER > 0 as the specialisation constraint.
I was aware of the general problem concerning literals and gave up the idea of defining subtypes of INTEGER a long time ago. I gave that example only because the IM extensions to Tutorial D require derived possreps to be given in such cases. These are impossible with subtypes of system-defined types unless system-defined types have possreps. An alternative is to change the IM extensions to Tutorial D, currently as given in DBE Chapter 21. But as I wrote before, the Rel expression INTEGER(1) strongly suggests the existence of a singleton possrep for type INTEGER, so provision of a corresponding THE_ operator would be expected.
Anyway, I've added a note to the relevant section of Chapter 21 in the on-line free download copy of DBE, suggesting that possreps can (optionally) be omitted when defining a subtype of a system-defined type.
Hugh
I was aware of the general problem concerning literals and gave up the idea of defining subtypes of INTEGER a long time ago. I gave that example only because the IM extensions to Tutorial D require derived possreps to be given in such cases. These are impossible with subtypes of system-defined types unless system-defined types have possreps. An alternative is to change the IM extensions to Tutorial D, currently as given in DBE Chapter 21. But as I wrote before, the Rel expression INTEGER(1) strongly suggests the existence of a singleton possrep for type INTEGER, so provision of a corresponding THE_ operator would be expected.
Anyway, I've added a note to the relevant section of Chapter 21 in the on-line free download copy of DBE, suggesting that possreps can (optionally) be omitted when defining a subtype of a system-defined type.
Hugh
Re: possreps for system-defined types
I've made a note in the TODO list to provide THE_INTEGER(INTEGER) RETURNS INTEGER.