Re: Entity and Identity

From: Nilone <reaanb_at_gmail.com>
Date: Sat, 8 Aug 2009 21:08:21 -0700 (PDT)
Message-ID: <87452003-a7f5-4706-a190-1ad067992718_at_d23g2000vbm.googlegroups.com>


On Aug 8, 12:03 am, rp_at_raampje.(none) (Reinier Post) wrote:
> Nilone wrote:
>
> [...]
>
> >> So what is your alternative for expressing dynamics (behavior)
> >> in a disciplined,maintainable  way?  Is a big bag of procedures
> >> that can query and update arbitrary data as they please *better*?
>
> >> --
> >> Reinier
>
> >I've already accepted that OO classes are appropriate for creating
> >state machines, hence I'm not offering alternatives.  Note that "a big
> >bag of procedures that can query and update arbitrary data as they
> >please" is an unfair characterization of procedural programming,
> >similar to "a big bag of objects that can query and update each other
> >as they please".
>
> My question is: how do you propose to organize them?
> Do you agree that some disciplining in how code can access objects
> is required?  What do you propose code should look like
> (you write 'relational all the way', what does relational GUI
> code look like - not that I can't imagine any).
>
> --
> Reinier

Here is a rough description of a hypothetical type system for a programming language. My terminology is based on C#, but the logic is based on relational theory. Static GUIs are easy enough to describe in a DB, the difficult part is describing dynamic behavior, which I hope to achieve by associating functions and state machines with data types (i.e. RM headings).

  1. Data types

Structs and classes both allow for the creation of composite structures of data types and functions. Declaration of data types should be separated from memory allocation and variable semantics. Composite data type are just the derivation of new data types from existing data types via composition, projection (as in RM), extension (addition of attributes) or constraint (covariant overriding). Derivation via extension or constraint is called subtyping.

Attributes of a data type are named, and can be primitive data types (bool, byte, short, int, long, float, double, date, etc), composite data types, functions (derived attributes) or function-typed (i.e. delegates).

2. Values

A value is data in memory associated with a type. Values are immutable constructs, created by parametrized constructor functions. Equality of values of compatible types is defined as equality of the values of corresponding attributes.

3. State machines

A state machine is derived from a data type, and consists of a set of methods which describe transitions between values of the associated type. A state machines can define an interface, or implement one or more existing interfaces.

Every instance of a state machine has an implicit variable containing the state of that instance as a value of the associated type. In addition, an instance of a state machine may hold references to instances of other state machines.

State machines are initialized via a constructor method, which may be parametrized. State machines may also define destructor methods.

4. Interfaces

An interface is a published data type, optionally with one or more associated state machines, and optionally with limitations on access by clients.

5. Variables

Variables hold values, instances of state machines, or references (to values or instances of state machines). The contents of a variable is determined by the assignment to the variable. Variables are mutable. The contents of a variable is always passed as is.

6. Collections

Variables can be declared as homogeneous sets of values / state machines / references. The usual semantics associated with sets apply, in addition to selection/restriction by attributes. Received on Sun Aug 09 2009 - 06:08:21 CEST

Original text of this message