User Tools

Site Tools


introduction

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

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 wordscomponents 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 Javaexcept ​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