Arden Objects Proposal Arden SIG Meeting Jan 14

Arden Objects Proposal Arden SIG Meeting Jan. 14, 2003 San Antonio, Texas Presented by Roger Corman

Introduction l This proposal follows the Mc. Kesson presentation by Tom Hooks at the previous Arden SIG meeting. l It attempts to incorporate most of the ideas Tom presented in the Phase 3 approach. l Adds syntax for object definition. l Adds more formalism (B/N Forms)

Introduction (cont. ) This is still an incomplete proposal: a few issues are not covered and presumably will be topics of discussion.

Goals l Simplify handling of query results. l Keeping query results as a list of objects/records is often more convenient and intuitive. l Creates a standard way to have named object/attributes in the system. This may allow platform-specific extensions to other objects to still share much of the object manipulation logic. l Maintain backward compatibility.

Language Goals l Keep added syntax/reserved words to a minimum. l Any changes should work with existing Arden as seamlessly as possible. l Coax the objects out of Arden, rather than impose a new model. l Simplicity.

Object Declaration Statement The OBJECT statement definition: <var> : = OBJECT [ <field-name-1>, <field-name-2>. . . ]; LET <var> BE OBJECT [ <field-name-1>, <fieldname-2>. . . ]; Field names are Arden identifiers. Example: l Medication. Dose : = object [Medication, Dose, Status];

Object Declaration Statement (cont. ) Object declaration statements can only occur in the Data Slot, and they must occur prior to any use of the object type. This is similar to an MLM or DESTINATION declaration.

Object Declaration: Syntax Modifications Add OBJECT as an Arden reserved word. This is the only new reserved word being proposed, and possibly the only backward compatibility issue.

Object Declaration: Syntax Modifications l Added <object_definition>: <object_definition> : : = "[" <object_attribute_list> "]" l Added <object_attribute_list>: <object_attribute_list> : : = <identifier> | <identifier> ", " <object_attribute_list>

Object Attribute References l Implement “dot notation” for referring to attributes of objects. l If an object attribute contains another object, the dots can be strung together. Example: patient. weight. units

Object Attribute References: Dot Operator 9. 12. xx Dot (binary) The dot (. ) operator is used to select an attribute from an object, based on the name following the dot. It takes an expression and an identifier. The expression typically evaluates to a structure or a list of structures. Its usage is: <n: any-type> : = <expr>. <identifier> If the expression does not evaluate to an object, null is returned. If the expression evaluates to a list, normal Arden list handling is used and a list is returned.

Object Attribute References: Dot Operator (cont. ) Dot Operator Example: Name. Type : = object [First. Name, Middle. Name, Last. Name]; /* Assume namelist contains a list of 3 Name. Type objects */ (“John”, “Paul”, “George”) : = namelist. First. Name; (“Lennon”, “Mc. Cartney”, “Bush”) : = namelist. Last. Name; “John” : = namelist[1]. First. Name; null : = namelist[1]. Height; (null, null) : = namelist. Height;

Object Attribute References: Syntax Modifications Added “. ” operator. This is at the same precedence level as the Element operator. <expr_factor> : : = <expr_factor_atom> | <expr_factor_atom> "[" <expr> "]" | <expr_factor> ". " <identifier>

READ AS Statement l READ AS is a structured READ. l Instead of returning a list of columns from a query, it returns a list of rows (objects). l The returned objects will match the type specified. <var> : = READ AS <object-type> <aggregation> <mapping> WHERE <constraint>; LET <var> BE READ AS <object-type> <aggregation> <mapping> WHERE <constraint>;

READ AS Example 1 Example: Medication. Dose : = object [Medication, Dose, Status]; med_doses : = read as Medication. Dose { select med, dosage, status from client where status != "inactive" }; write med_doses; /* outputs something like the following */ [Medication. Dose: Medication="Med 1", Dose="Dose 1", Status="Active"], [Medication. Dose: Medication="Med 2", Dose="Dose 2", Status="Active"], [Medication. Dose: Medication="Med 3", Dose="Dose 3", Status="Active"] write med_doses. Medication; /* outputs */ "Med 1", "Med 2", "Med 3"

READ AS Example 2 Example: Medication. Dose : = object [Medication, Dose, Status]; med_doses : = read as Medication. Dose last ({ select med, dosage, status from client where status != "inactive" } where it occurred within the past 2 weeks); write med_doses; /* outputs something like the following */ [Medication. Dose: Medication="Med 3", Dose="Dose 3", Status="Active"]

Primary Time Attributes retain primary times, and expressions like: TIME OF Renal_function. BUN_level will work as expected. l To be decided: Should objects have a primary time?

Filtering Lists of Objects l WHERE clause supports lists of objects. l Attributes can be appended to "it" and "they" synonyms. // List of objects returned Bp_r_arm : = bp where it. site = "R Arm“; // Simple list returned Elevated_systolic : = bp. systolic where it > 140;

Remaining Issues l Object Time l Object Value l Assignment to attributes l Assignment of objects (by value vs. by reference) l Behavior of other operators when passed objects. Most operators will only support attributes, and will treat an object as an unknown type. A few may need some appropriate behavior.

Operator Modifications Aggregation operators such as LATEST, EARLIEST, MINIMUM, MAXIMUM can easily be applied to an attribute of a list of objects: Max : = maximum of obj_list. attr 1; However, Max now contains only the attribute value, not the object itself. We should probably specify how and when the object itself may be returned.

SORT We should specify a way to sort on any field. Sorted_list : = sort <attr> data unsorted_list; Where <attr> could be any attribute, and the sorted list returned is a list of objects.

Object Time We may want to define a time for the object, so: TIME of obj is a reasonable expression. This allows LATEST and EARLIEST to work as expected, and helps make object use simpler in other places as well. Perhaps if all fields have the same time, this automatically becomes the object time, otherwise it is null.

Object Value In Mc. Kesson’s presentation, they suggested a default Value field, which would be used if no attribute was specified when objects were passed to Arden operators. I have some questions about this i. e. what if a list contains some objects and some non-objects. Does the value field of the objects get taken and the nonobjects used directly? We need to think about this a bit.

Assignment of Attributes It is easy to implement assignment of attributes i. e. the left side of an assignment statement can use the dot notation. However, this comes back to the question of value/reference semantics which we brought up last meeting but has not been resolved.

Assignment of Attributes (cont. ) Example: Assume x is an object with attribute a. y : = x; x. a : = 10; Question: Did y. a get modified? If we assume reference semantics of objects, then y. a also got modified. If we assume value semantics, then x. a and y. a are separate variables. I believe that reference semantics is more useful, powerful and convenient. It is used in most OO languages such as Java, C#, C++ (typically but not always since both are allowed), Common Lisp, VB. NET, Smalltalk, etc.

Creation of Objects It would be useful to be able to construct objects on the fly, rather than having to use lists to simulate them (as is typically done now). I have not proposed a syntax for object construction. The only way to obtain objects in this proposal is via the READ AS statement.