Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "LDT/Developer Area/Lua API Model 2"

< LDT
(Sample)
 
(10 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
=Lua API Model=
 
=Lua API Model=
  
The idea is to define a model of the external API of a Lua file, a way to express a contract.<br/>
+
The idea is to define a model of the external API of a Lua file.<br/>
This model will be used as input of:
+
This model will then be the main input of:
* a documentation generator,
+
* documentation generator,
 
* auto-completion engine,
 
* auto-completion engine,
* type checking at IDE side.
+
* type-checking.
 +
 
 +
The code relative to this model is based on lua and metalua, it is accessible [[LDT/MetaLua|here]].
 +
This model is build from [[LDT/User_Area/Documentation_Language|lua documentation language]] in code comments and later from lua code analysis. (see also : [[LDT/Developer_Area/Lua_Comment_Model|Lua Comment Model]])
  
 
====File====
 
====File====
A Lua file declare some global variable and types.
+
A Lua file declares some global variable and types.
A file return values (this is the value you get when you require this file)  
+
A file returns values (this is the values you get when you require this file)  
 
   
 
   
 
  file
 
  file
Line 19: Line 22:
  
 
====TypeDef====
 
====TypeDef====
There are some primitive type like string, number, boolean, any, nil, table, function (we must define it more precisely)<br/>
+
There are some primitive types like string, number, boolean, any, nil, table, function.<br/>
TypeDef allow users to define, theirs own types.<br/>
+
TypeDef allow users to define theirs own custom types.<br/>
There are 2 kind of typedef.
+
There are 2 kinds of typedef.
  
  typeDef=recordDef | functionDef
+
  typeDef = recordTypeDef | functionTypeDef
 
   
 
   
a recordTypeDef could be used to define a type of record(a tuple), a module or an object. (it's surely a subtype of table)
+
A recordTypeDef can be used to define a record (a tuple), a module or an object. (It may be a sub-type of table)
  
 
  recordTypeDef
 
  recordTypeDef
  .string namme
+
  .string name
 
  .string shortdescription
 
  .string shortdescription
 
  .string description
 
  .string description
 
  .map(fieldname,item) fields
 
  .map(fieldname,item) fields
 
   
 
   
a functionTypeDef allow to define a type of function. Most of the time, the type and the item which hold it is merged.
+
A functionTypeDef allows to define a function. Most of the time, the type and the item holding it are merged.
Maybe, it could be usefull to named a type of function (for iterator perhaps)
+
It may be useful to name the type of function (for iterator perhaps)
  
  funtionTypeDef
+
  functionTypeDef
 
  .string name
 
  .string name
 
  .string shortdescription
 
  .string shortdescription
Line 52: Line 55:
 
  (.boolean hidden)
 
  (.boolean hidden)
  
'''Remarks''': Hidden could be usefull, if we have a parameter we don't want to expose in the API<br/>
+
'''Remarks''': Hidden could be use when there is a parameter we don't want to expose in the API<br/>
'''Remarks''': Hidden and optional does not need to be in the 1st version.
+
'''Remarks''': hidden and optional does not need to be in the 1st version.
  
 
====Item====
 
====Item====
Line 65: Line 68:
  
 
====TypeRef====
 
====TypeRef====
It's a reference to a type. There 3 kind of reference.
+
It's a reference to a type. There are 3 kinds of reference.
  
 
  typeref: externaltyperef | internaltyperef |primitivetyperef
 
  typeref: externaltyperef | internaltyperef |primitivetyperef
Line 80: Line 83:
  
 
====Return values====
 
====Return values====
a values return has references to a type define in the Lua file.
+
A return value has references to a type defined in the Lua file.
a values return is a list of possible value to return.
+
A return value is a list of possible values to return.
  
e.g. if a function return a number or nil and err.
+
e.g. if a function returns a number, or nil and err.
you function will have 2 return values :
+
your function will have 2 return values :
- number a result
+
* <code>number</code> a result
- nil, err if an error occured
+
* <code>nil, err</code> if an error occured
  
 
  return
 
  return
Line 93: Line 96:
 
  (.defaultuse)
 
  (.defaultuse)
  
'''Remarks''': Perhaps we could have a defaultuse entry to define the return value the type checking should use. Currently we use the first entry as defaultuse.
+
'''Remarks''': Perhaps we could have a defaultuse entry to define the return value the type checker should use. At the moment, the first entry in types list is used to type the return value.
 
+
= Documentation Language  =
+
 
+
== Sample  ==
+
 
+
------------------------------------------------------------------------------
+
-- short description.
+
-- long description
+
-- @module modulename
+
-- @return #primitivetyperef, my.module#externaltyperef, #internaltyperef description
+
+
-----------------------------------------------------------------------------
+
-- short description.
+
-- long descrition
+
-- @type #recordtypename
+
-- @field #typeref fieldtypedname description
+
-- @field fieldnottypedname description
+
+
-----------------------------------------------------------------------------
+
-- short description.
+
-- long description
+
-- @function [parent=#global] functionname
+
-- @param #typref typedparamname description
+
-- @param untypedparamname description
+
-- @return #typeref, #typeref description
+
+
------------------------------------------------------------------------------
+
-- short description.
+
-- long descrition
+
-- @function [parent=#recordtyperef]
+
-- @param #typeref paramtypedname description
+
-- @param paramnottypedname description
+
-- @return #typeref,#typeref decription
+
 
+
------------------------------------------------------------------------------
+
-- short description.
+
-- long descrition
+
-- @field[parent=#global] #typref fieldname
+
 
+
------------------------------------------------------------------------------
+
-- short description.
+
-- long descrition
+
-- @field[parent=#recordtyperef] #typref fieldname
+
 
+
== Sample detailed explanation  ==
+
 
+
=== File comment block  ===
+
 
+
------------------------------------------------------------------------------
+
-- short description.
+
-- long description
+
-- @module modulename
+
-- @return #primitivetyperef, my.module#externaltyperef, #internaltyperef description
+
------------------------------------------------------------------------------
+
 
+
This section will be processed as '''module documentation block''', when keyword <code>@module</code> is found.
+
Several <code>@return</code> clauses are allowed. They are composed of a list of several type references.
+
Those references represent types returned by this file.
+
There are three kinds of type references:
+
* '''primitive''': reference to a built in type as <code>string</code>, <code>table</code>, <code>boolean</code>, ... In our syntax: <code>#string</code>, <code>#table</code>, <code>#boolean</code>, ...
+
* '''internal''': reference to types defined in '''current file'''. Such as <code>#internaltyperef</code> in previous sample.
+
* '''external''': reference to types defined in '''other modules'''. Such as : <code>my.module#externaltyperef</code>.
+
Textual '''description''' is everything till next line starting with <code>@</code>.
+
If not return is defined, the module will return an record internal type named #modulename.
+
 
+
=== Record comment block ===
+
------------------------------------------------------------------------------
+
-- short description.
+
-- long descrition
+
-- @type #recordtypename
+
-- @field #typeref fieldtypedname description
+
-- @field fieldnottypedname description
+
------------------------------------------------------------------------------
+
Will be processed as a '''type comment block''', when keyword <code>@type</code> is found.
+
Several <code>@field</code> clauses are allowed. They consist of the keyword <code>@field</code> followed by an optional type reference as described in the file comment section, then follow field name and textual description.
+
Textual description is '''everything''' till next line starting with <code>@</code>.
+
 
+
===Function comment block===
+
------------------------------------------------------------------------------
+
-- short description.
+
-- long description
+
-- @function [parent=#global] functionname
+
-- @param #typref typedparamname description
+
-- @param untypedparamname description
+
-- @return #typeref,#typeref description
+
------------------------------------------------------------------------------
+
Will be processed as a function comment block, when keyword <code>@function</code>.
+
This keyword is followed by a scope indicator:
+
* '''[parent = #global]''': to specify that this function will be stored in global environment.
+
* '''[parent = #internalrecordtyperef]''': where <code>#internalrecordtyperef</code> is a reference to a record type defined in current file. It allows to link this function to referenced record type.
+
Function name is optional.
+
Several <code>@param</code> clauses are allowed.  They consist of <code>@param</code>  followed by an '''optional''' type, a parameter name and a textual description, which is everything until next line starting with a <code>@</code>.
+
Several <code>@return</code> clauses are allowed. They consist of <code>@return</code> followed by a list of type references separated by comas and a textual description as previously described.
+

Latest revision as of 12:35, 16 July 2014

Lua API Model

The idea is to define a model of the external API of a Lua file.
This model will then be the main input of:

  • documentation generator,
  • auto-completion engine,
  • type-checking.

The code relative to this model is based on lua and metalua, it is accessible here. This model is build from lua documentation language in code comments and later from lua code analysis. (see also : Lua Comment Model)

File

A Lua file declares some global variable and types. A file returns values (this is the values you get when you require this file)

file
.string shortdescription
.string description
.map(typename, typedef) types
.map(varname,item) globalvars
.list(returnvalues) returns

TypeDef

There are some primitive types like string, number, boolean, any, nil, table, function.
TypeDef allow users to define theirs own custom types.
There are 2 kinds of typedef.

typeDef = recordTypeDef | functionTypeDef

A recordTypeDef can be used to define a record (a tuple), a module or an object. (It may be a sub-type of table)

recordTypeDef
.string name
.string shortdescription
.string description
.map(fieldname,item) fields

A functionTypeDef allows to define a function. Most of the time, the type and the item holding it are merged. It may be useful to name the type of function (for iterator perhaps)

functionTypeDef
.string name
.string shortdescription
.string description
.list(parameter) params
.list(returnvalues) returns

Parameter

parameter
.string name 
.typeref type
.string description
(.boolean optional)
(.boolean hidden)

Remarks: Hidden could be use when there is a parameter we don't want to expose in the API
Remarks: hidden and optional does not need to be in the 1st version.

Item

item
.string name
.string shortdescription
.string description
.typeref type


TypeRef

It's a reference to a type. There are 3 kinds of reference.

typeref: externaltyperef | internaltyperef |primitivetyperef

externaltyperef
.string modulename
.string typename

internaltyperef
.string typename

primitivetyperef
.string typename

Return values

A return value has references to a type defined in the Lua file. A return value is a list of possible values to return.

e.g. if a function returns a number, or nil and err. your function will have 2 return values :

  • number a result
  • nil, err if an error occured
return
.list(typeref) types
.string description
(.defaultuse)

Remarks: Perhaps we could have a defaultuse entry to define the return value the type checker should use. At the moment, the first entry in types list is used to type the return value.

Back to the top