-
-
Notifications
You must be signed in to change notification settings - Fork 112
Aggregate Types Design (Working Draft)
This is a working draft document and is not representative of the final implementation.
A specification for introducing aggregate types into the Concerto language.
For example:
map AddressBook {
o GUID
o Person
}
set MyFruit {
o Fruit
}
union Party {
o Individual
o Corporation
o Charity
}
list Friends {
o Person
}
concept MyConcept {
o AddressBook people
o MyFruit fruit
o Party party1
}
These definitions are used in the worked examples in this document.
concept Thing {}
concept Person identified {}
enum Phase {
o ONE
o TWO
}
scalar GUID extends String
event Activity {}
The map
declaration holds key-value pairs and remembers the original insertion order of the keys.
namespace com.acme@1.0.0
map Dictionary {
o String
o String
}
map Checklist {
o String
o Boolean
}
map Timeline {
o DateTime // similarly for any primitive type, except Integer, Long, Double.
o Activity
}
map AddressBook {
o GUID // similarly for scalars that extend one of the supported primitive key types.
o Person
}
map AddressBook2 {
o GUID
--> Person
}
map StateMachine {
o Phase
o String
}
map Library {
o String
o Dictionary
}
map MarriageRegister {
o Person
o Person
}
concept Concept {
o Dictionary dictionary
o Checklist checklist
o Timeline timeline
o AddressBook addressBook
o AddressBook remoteEmployees
o StateMachine state
o Dictionary[] arrayOfRecords
o Dictionary optionalRecord optional
o Library library // nested record
o MarriageRegister marriages // complex key
// NOT SUPPORTED
// --> Dictionary record1
}
// NOT SUPPORTED
// map Bad {
// o Thing
// o Person
// }
Imports
import [email protected]
- Each
map
declaration must have two properties. - The first properties indicates the type of the key in the map.
- The second property indicates the type of the value in the map.
- Ordering of values in a map follows the insertion order.
- Maps should be implemented using the JavaScript
Map
object. We inherit the semantics of that implementation here. - Serialization and deserialization should maintain the order of elements in the object.
- The fully qualified type name follow the same format as for
concept
declarations, e.g.[email protected]
Concerto maps are serialized to JSON objects with keys serialized to strings. This why we don't allow number index types. The value is the normal JSON serialization of the value.
{
"$class": "[email protected]",
"value": {
"123-34-12-1234": { "$class": "Person", ... },
"234-45-56-1234": { "$class": "Person", ... }
}
}
Impact on code generation tools: [TBD]
- TypeScript:
map
in Concerto should become TypeScriptRecord<S, T>
types.
The set
declaration lets you store unique values for a type. Supported types a primitive values, identified complex types, enums and relationships.
set StringSet {
o String // similarly for any primitive type, or scalar
}
set EnumSet {
o Phase
}
set ComplexTypeSet {
o Person
}
set RelationshipSet {
--> Person
}
- A value in a set must only appear once.
- The order of values in a set respects the order that entries were added to the set.
- Sets should be implemented using the JavaScript
Set
object. We inherit the semantics of that implementation here. - The fully qualified type name follow the same format as for
concept
declarations, e.g.[email protected]
{ "$class": "[email protected]", "value": ["foo", "bar", "baz"] }
{ "$class": "[email protected]", "value": ["ONE", "TWO"] }
{ "$class": "[email protected]", "value": [{ "$class": "Person", ... }, { "$class": "Person", ... }] }
{ "$class": "[email protected]", "value": ["resource1", "resource2"] }
Impact on code generation tools: [TBD]
union Party {
o Individual
o Corporation
o Charity
}
concept Agreement {
o Party party
}
- ...
[TBD]
Impact on code generation tools: [TBD]