introduction
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
introduction [2014/01/04 11:15] barryfp |
introduction [2014/04/22 09:10] barryfp |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| <div justify> | <div justify> | ||
| - | Dana programs are structured as collections of ''components''. Each Dana source file represents one such component. Each component implements one or more ''objects'' where each object is, in turn, a collection of one or more ''object types'' (in other words, components can form object implementations that exhibit multiple object types). | + | Dana programs are structured as collections of ''components''. Each Dana source file represents one such component. Each component implements one or more instantiable ''micro-components'' where each microcom is, in turn, a collection of one or more ''interfaces''. Microcoms can be thought of like "objects" in languages like Java, except that microcoms are instantiated by interface and the only requirement for compatability between two microcoms is that they share a common primary interface; they may have different secondary interfaces and different internal state. We generally use the more familiar term "object" throughout this documentation. |
| </div> | </div> | ||
| <div justify> | <div justify> | ||
| - | An object type is a collection of one or more function prototypes (object types cannot contain any "fields"). Object types therefore tend to represent behaviour in Dana programs while data tends to be represented by record types. | + | An interface type is a collection of one or more function prototypes (interface types cannot contain any "fields"). Objects therefore tend to represent behaviour in Dana programs while data tends to be represented by record types. |
| </div> | </div> | ||
| Line 14: | Line 14: | ||
| <div justify> | <div justify> | ||
| - | As well as implementing a collection of objects, each component declares a number of ''required object types'', representing other components on which the functionality of this component depends. These explicit required object types are the basis of Dana's core purpose: enabling unparalleled re-usability of code and supporting meta-software-reasoning. These capabilities stem from the principle that a component never resolves its own dependencies, but rather an external entity (a meta-program) is responsible for this. Meta-programs can examine and seamlessly re-wire dependencies to other components while software is running. Meta-programs are themselves composed of Dana components. | + | As well as implementing a collection of objects, each component declares a number of ''required interfaces'', representing other components on which the functionality of this component depends. These explicit required interfaces are the basis of Dana's core purpose: enabling unparalleled re-usability of code and supporting meta-software-reasoning. These capabilities stem from the principle that a component never resolves its own dependencies, but rather an external entity (a meta-program) is responsible for this. Meta-programs can examine and seamlessly re-wire dependencies to other components while software is running. Meta-programs are themselves composed of Dana components. |
| </div> | </div> | ||
introduction.txt ยท Last modified: 2014/04/22 09:10 by barryfp
Page Tools
