User Tools

Site Tools


introduction

Differences

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

Link to this comparison view

Next revision
Previous revision
introduction [2014/01/04 09:22]
barryfp created
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 component. Each component implements one or more objects ​where each object ​is 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 (more on this later).+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 box round> 
 +<div centeralign>​ 
 +{{:​basics.png?​nolink|}} 
 +</​div>​
 </​div>​ </​div>​
  
 <div justify> <div justify>
-As well as implementing a collection of objects, each component ​also 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 box round> 
 +<div centeralign>​ 
 +{{:​requires.png?​nolink|}} 
 +</​div>​
 </​div>​ </​div>​
  
introduction.txt · Last modified: 2014/04/22 09:10 by barryfp