Main.Things History
Hide minor edits - Show changes to output
Changed lines 75-76 from:
Even though '''ThingML is not an OO language, and thus does not provide plain inheritance''', the thing fragment declaring the messages can be seen as an interface, which can be realized by different concrete things. The example above would then be refined into:
to:
Even though '''ThingML is not an OO language, and thus does not provide plain inheritance''', it provides some basic mechanisms to improve the modularity/reusability of fragments of ThingML provides.
A thing fragment can been seen as an interface or abstract class. Typically it declares some messages, but could also define any feature we can find in plan things.
The example defined in the '''Port''' section, would then be rafactored into:
A thing fragment can been seen as an interface or abstract class. Typically it declares some messages, but could also define any feature we can find in plan things.
The example defined in the '''Port''' section, would then be rafactored into:
Added line 82:
//Interface for the service A
Added line 90:
//Concrete thing providing A
Added line 98:
//Concrete thing using A
Changed line 108 from:
The "includes" keyword is basically related to extends/implements/inherits in OO language. However, the semantic of this include is very simple: it basically means that what is defined in the fragment is "copy-pasted" into the thing including this fragment. No "super", "override" or the like.
to:
The "includes" keyword is basically related to extends/implements/inherits in OO language. However, the semantic of this include is very simple: it basically means that what is defined in the fragment is "copy-pasted" into the thing including this fragment. No more, no less. No "super", "override" or the like.
Changed lines 67-68 from:
Note that usually, messages are defined in a thing fragment, that can be included in the different things using these messages. Even though '''ThingML is not an OO language, and thus does not provide plain inheritance''', the thing fragment declaring the messages can be seen as an interface, which can be realized by different concrete things. The example above would then be refined into:
to:
Note that usually, messages are defined in a thing fragment, that can be included in the different things using these messages. See the section about '''includes and fragments''' on this page, which provides a refactoring of this example.
!!!State Machines
[[https://thingml.org/pmwiki.php?n=Main.StateMachines | This topic is detailed here]]
!!!Includes and fragments
Even though '''ThingML is not an OO language, and thus does not provide plain inheritance''', the thing fragment declaring the messages can be seen as an interface, which can be realized by different concrete things. The example above would then be refined into:
!!!State Machines
[[https://thingml.org/pmwiki.php?n=Main.StateMachines | This topic is detailed here]]
!!!Includes and fragments
Even though '''ThingML is not an OO language, and thus does not provide plain inheritance''', the thing fragment declaring the messages can be seen as an interface, which can be realized by different concrete things. The example above would then be refined into:
Changed lines 101-105 from:
[[http:
!!!Includes and fragments
to:
The "includes" keyword is basically related to extends/implements/inherits in OO language. However, the semantic of this include is very simple: it basically means that what is defined in the fragment is "copy-pasted" into the thing including this fragment. No "super", "override" or the like.
Changed line 18 from:
Properties are global variables defined in the scope of a thing. A Property is typed by a datatype, for example:
to:
Properties are global variables defined in the scope of a thing. A Property is typed by a [[https://thingml.org/pmwiki.php?n=Main.DataTypes | datatype]], for example:
Added lines 23-25:
// definition of a property of type String, with initial value
property myStringProperty : String = "init"
property myStringProperty : String = "init"
Changed lines 36-37 from:
These properties cannot be modified in a ThingML program. However, note that constants can be refined once, when instantiating a thing in a [[https://thingml.org/pmwiki.php?n=Main.Configurations | configuration]]. Each instance of a thing can thus be affected a different value for this constant.
to:
These constant properties cannot be modified in a ThingML program. However, note that constants can be refined once, when instantiating a thing in a [[https://thingml.org/pmwiki.php?n=Main.Configurations | configuration]]. Each instance of a thing can thus be affected a different value for this constant.
Added lines 50-91:
Ports allows grouping messages into coherent units. Basically, a thing providing a service will declare something like
[@
thing MyThingProvidingServiceA {
//request to get the status of the sensor called name
message getState(name : String)
//response
message sendState(name : String, state : DigitalState );
provided port ServiceA {
receives getState
sends sendState
}
}
@]
Note that usually, messages are defined in a thing fragment, that can be included in the different things using these messages. Even though '''ThingML is not an OO language, and thus does not provide plain inheritance''', the thing fragment declaring the messages can be seen as an interface, which can be realized by different concrete things. The example above would then be refined into:
[@
thing fragment ServiceAMsgs {
//request to get the status of the sensor called name
message getState(name : String)
//response
message sendState(name : String, state : DigitalState );
}
thing MyThingProvidingServiceA includes ServiceAMsgs{
provided port ServiceA {
receives getState
sends sendState
}
}
thing MyThingRequiringServiceA includes ServiceAMsgs{
//This is basically the mirror of the port in the previous thing
required port ServiceA {
sends getState
receives sendState
}
}
@]
Changed lines 35-36 from:
'''Note''' that variables defined in the scope of block of code (inside a state, a transition or in a function) are declared in the same way, by replacing the keyword 'property' by 'var'
to:
'''Note''' that local variables can be defined in states, exactly in the same way. For local variables defined in the scope of block of code (inside the actions of a state or a transition or in a function) they are declared in a similar way, by replacing the keyword 'property' by 'var'
Added lines 49-50:
[[https://thingml.org/pmwiki.php?n=Main.StateMachines | This topic is detailed here]]
Added lines 38-44:
ThingML state machines communicate by exchanging messages in an asynchronous way. The declaration of a message in ThingML is quite similar, from a syntactical point of view, to the declaration of methods in a Java interface
[@
//defintion of a message with two parameters
message sendState(name : String, state : DigitalState );
@]
Changed line 19 from:
to:
[@
Changed lines 25-26 from:
to:
@]
Changed line 28 from:
to:
[@
Changed lines 31-32 from:
to:
@]
Added lines 34-35:
'''Note''' that variables defined in the scope of block of code (inside a state, a transition or in a function) are declared in the same way, by replacing the keyword 'property' by 'var'
Changed line 31 from:
These properties cannot be modified in a ThingML program. However, note that constants can be refined once, when instantiating a thing in a [[configuration | https://thingml.org/pmwiki.php?n=Main.Configurations]]. Each instance of a thing can thus be affected a different value for this constant.
to:
These properties cannot be modified in a ThingML program. However, note that constants can be refined once, when instantiating a thing in a [[https://thingml.org/pmwiki.php?n=Main.Configurations | configuration]]. Each instance of a thing can thus be affected a different value for this constant.
Added lines 17-31:
Properties are global variables defined in the scope of a thing. A Property is typed by a datatype, for example:
// definition of a property of type Integer
property myProperty : Integer
// definition of a property of type DigitalState
property state: DigitalState
Properties can also be used to define constant. In that case we should prefix they declaration by readonly:
// definition of a property of type Integer
readonly property myProperty : Integer = 16
These properties cannot be modified in a ThingML program. However, note that constants can be refined once, when instantiating a thing in a [[configuration | https://thingml.org/pmwiki.php?n=Main.Configurations]]. Each instance of a thing can thus be affected a different value for this constant.
Changed lines 3-4 from:
The core concept of ThingML is "thing". A ThingML things defines a component which can send and receive a set of messages asynchronously. Messages are sent and received via ports. The overall behavior of a "thing" is defined using a state machine.
to:
The core concept of ThingML is "thing". A thing defines a component which can send and receive a set of messages asynchronously. Messages are sent and received via ports. The overall behavior of a "thing" is defined using a state machine.
Here is the syntax for the definition of a thing:
Here is the syntax for the definition of a thing:
Changed lines 8-13 from:
thing myThing {}
to:
thing myThing {
/* Some properties */
/* Some messages */
/* Some ports */
/* Some state machines */
}
/* Some properties */
/* Some messages */
/* Some ports */
/* Some state machines */
}
Added lines 16-24:
!!!Properties
!!!Messages
!!!Ports
!!!State Machines
!!!Includes and fragments
!!!Messages
!!!Ports
!!!State Machines
!!!Includes and fragments
Added lines 1-9:
!!Things, messages and ports
The core concept of ThingML is "thing". A ThingML things defines a component which can send and receive a set of messages asynchronously. Messages are sent and received via ports. The overall behavior of a "thing" is defined using a state machine.
[@
// definition of an empty thing
thing myThing {}
@]
The core concept of ThingML is "thing". A ThingML things defines a component which can send and receive a set of messages asynchronously. Messages are sent and received via ports. The overall behavior of a "thing" is defined using a state machine.
[@
// definition of an empty thing
thing myThing {}
@]