These files can import data type definitions from delphi.
They are run by the frontend,
which analyzes the files specified within and generates a
corresponding User Type Definition
You have to be careful to edit a file with the ending .g.yml,
This is the convention for automatic generated types, which will be overwritten by every converter run.
The format itself is a simple but sufficient DSL, as the example from the Demo will show you:
guid F3BB89AE-F2D0-494C-87CF-3F7822544FA9
from ..\..\Delphi
in HybrieDemoInclude.pas
import*end
Important: you can specifiy mulitple in/import/using pairs within a from ... end block,
This will import several types at once (useful for dependent files)
Keywords:
from
This keyword loads a directory for input processing
in
Specifies a delphi source file from which to import data types. (wildcards not supported yet)
import
This can either be a concrete type name or a wildcard *,
Which imports all files, which is the preferred option.
using
This is an optional keyword and is required if you don't want to import the file into the output folder,
But rather you want to use one of your packages this file is contained in.
This helps avoiding import conflicts within your Delphi project, as one unit can only be imported once in certain cases.
The input to the program is mostly defined in a human-editable markup format, based on the YAML specification.
Listed is a certain set of rules which have to be followed:
Every YAML document starts with a version and a document separator.
%YAML 1.2
---
The fully qualified name of the document is the root of all nodes, i.e. it serves as a common namespace.
When using a language which support namespaces, all elements will be defined in that namespace.
Following the Java package convention, the file name should match the namespace, this keeps things in order.
Import of other YAML documents, this is used by the User Type Definition engine to reference other types. It also imports the namespace as above
Tthe order of the keys in the hashmap does matter (i.e.)
In a future version, this requirement might be dropped, when there is a dependency resolution mechanism to resolve the order of statements.
Nonetheless, the implementation used does keep the input order intact, so it won't create any problems.
For defining remote callable modules in your programs, you need
an interface specification
For now, these need to be manually edited, but do not fear, it
follows a Common file specification based on YAML, so
Here you can define methods and their parameters, using .NET
primitive types, arrays and the User Type Definition.
To get a broader overview, here is a listing of the Demo
Project source file:
The data type specification is the core of the
interoperability between different computer languages.
Here is the data definition file from the Demo Project:
A document can use any number of elements, using these kinds of definitions:
Enum
A sequence of enum constant names to values, values can be defined or automatically valued:
Normal value: scalar (- NameOfConstant)
Explicit value: map (- NameOfConstant: Value)
Record
A sequence of maps name to types
Class
From the syntax point of view, the same as record. Once properly supported, will have class specific features.
Alias
This is induced by the frontend, if an alias is specified, no code will be generated for that language,
instead the given type will be referenced (works for delphi so far)