User Tools

Site Tools


code-organisation

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
code-organisation [2017/06/23 09:36]
barryfp
code-organisation [2018/06/07 09:10]
barryfp [Developing in the central source tree]
Line 1: Line 1:
-The previous ​section ​discussed some elements of source code organisation to create multi-component systems. This section describes the complete model behind this idea.+In this section ​we introduce the way in which source code is organised for projects that use multiple components, particularly how we separate **interfaces** from **implementations** ​a key feature of Dana's code re-use and runtime adaptation capabilities.
  
 Programs that you build in Dana are a mixture of your own components and components from Dana's central source tree, or CST (which is a bit like a standard library). All components in the CST are open-source so you can browse them yourself. You can also add your own components to the CST to make them available to multiple different programs. Programs that you build in Dana are a mixture of your own components and components from Dana's central source tree, or CST (which is a bit like a standard library). All components in the CST are open-source so you can browse them yourself. You can also add your own components to the CST to make them available to multiple different programs.
Line 13: Line 13:
 The green lines in this diagram indicate "​in-directory"​ relationships;​ the projectx directory therefore contains four items (two directories and two files) while the resources directory contains two items (one directory and one file) and so on. The green lines in this diagram indicate "​in-directory"​ relationships;​ the projectx directory therefore contains four items (two directories and two files) while the resources directory contains two items (one directory and one file) and so on.
  
-The resources directory, and its sub-directories,​ is used to contain source files that describe **interface** and **data types**. ​Generally speaking ​a source file that contains a type definition (such as an interface) should have the same file name as the type name that it defines.+The resources directory, and its sub-directories,​ is used to contain source files that describe **interface** and **data types**. ​In general, ​a source file that contains a type definition (such as an interface) should have the same file name as the type name that it defines.
  
-The projectx directory ​meanwhile, and each of its sub-directories (except for the resources sub-directory),​ contains source files of **components that implement interfaces**. The general convention for these source files is to name them with the same name as the main interface type that the component provides.+The projectx directory, and each of its sub-directories (except for the resources sub-directory),​ contains source files of **components that implement interfaces**. The general convention for these source files is to name them with the same name as the main interface type that the component provides.
  
 In the above example, the file ''​Road.dn''​ in the projectx directory therefore contains the source code for a component that provides the Road interface as defined in the resources directory. In the above example, the file ''​Road.dn''​ in the projectx directory therefore contains the source code for a component that provides the Road interface as defined in the resources directory.
Line 69: Line 69:
 You can also develop components in Dana's central source tree (CST). We generally advise against developing entire projects here but you may wish to place utility / shared components here that are useful across multiple projects. You can also develop components in Dana's central source tree (CST). We generally advise against developing entire projects here but you may wish to place utility / shared components here that are useful across multiple projects.
  
-Developing code in the CST is very similar ​to the local directory case described above, except that we do not use a "​resources"​ sub-directory. Instead ​the CST is split into two branches, "​components"​ and "​resources"​. These two branches have symmetrical structure (take look for yourself). +Developing code in the CST is identical ​to the local directory case described above (the CST is in fact just local project but is always available as default search path). When compiling a component, any interface types (other type files) are searched for by converting any dots to slashes, adding ''​.dn''​ to the end, and then looking in the resources directory of the CST for a file matching that name. However, the compiler will **also** search from the symmetrical location within the resources folder of the CST. Imagine, for example, that you have a component in a file called ''​File.dn''​ within the ''​io''​ sub-directory of the components directory in the CST. If this component uses an interface simply called ''​File'',​ the compiler will therefore look at both ''​resources/​File.dn''​ and ''​resources/​io/​File.dn''​ for this file.
- +
-When compiling a component, any interface types (other type files) are searched for by converting any dots to slashes, adding ''​.dn''​ to the end, and then looking in the resources directory of the CST for a file matching that name. However, the compiler will **also** search from the symmetrical location within the resources folder of the CST. Imagine, for example, that you have a component in a file called ''​File.dn''​ within the ''​io''​ sub-directory of the components directory in the CST. If this component uses an interface simply called ''​File'',​ the compiler will therefore look at both ''​resources/​File.dn''​ and ''​resources/​io/​File.dn''​ for this file.+
  
 At runtime, when attempting to resolve required interfaces of a component in the CST against default implementing components of those interfaces, the Dana runtime will perform a similar procedure. First, any dots in the interface type are converted to slashes and then ''​.o''​ is added to the end. The runtime then checks for a file in the components directory of the CST that matches the resulting path. At runtime, when attempting to resolve required interfaces of a component in the CST against default implementing components of those interfaces, the Dana runtime will perform a similar procedure. First, any dots in the interface type are converted to slashes and then ''​.o''​ is added to the end. The runtime then checks for a file in the components directory of the CST that matches the resulting path.
code-organisation.txt · Last modified: 2018/06/07 09:10 by barryfp