A property is a definition of an attribute (an instance variable) +with accessors. The property definition might carry as well +value-constraints and a default value.
+
+
+
+Figure 17. Classes Person and Student
+Note that the methods of the class Safety all end with next. +
Note that all the methods of the class Safety end with next. This command is a primitive command of NX, that will call the same-named method with the same argument list as the current invocation.
A variable without any colon prefix refers typically to a method scoped variable (the variable is created at the begin of the - invocation of the method and deleted, when the method ends); + invocation of the method and deleted, when the method ends). In the example below, the variable a is method scoped.
A variable with a single colon prefix refers to an instance variable (the variable is part of the object, when the object is destroyed, - the variable is deleted as well. In the example below, the variable + the variable is deleted as well). In the example below, the variable b is an instance variable.
-a variable with two leading colons refers to a global variable (the - lifespan ends when te variable is explicitly unset or the script - ends). Also variables in placed in Tcl namespaces are global - variables. In the example below, the variable c is a global - variable. +A variable with two leading colons refers to a global variable (the + lifespan of a globale variable ends when the variable is explicitly + unset or the script terminates). Variables in placed in Tcl + namespaces are also global variables. In the example below, the + variable c is a global variable.
Class create Foo { :method foo args {...} - # Method scoped variable a + # "a" is a method scoped variable set a 1 - # Instance variable b + # "b" is an Instance variable set :b 2 - # Global variable/namespaced variable c + # "c" is a global variable/namespaced variable set ::c 3 } }
So, in general, there is no need to define or declare instance variables in NX. However, in some cases, a definition is useful. For example, one can define properties on classes, which are inherited to -subclasses, and which are used during object initialization. Consider -the following example:
A property is a definition of an attribute (an instance variable) +with accessors. The property definition might carry as well +value-constraints and a default value.
+Consider the example above, where the classes Person and Student +are defined. Both classes have accessor methods for all their +attributes specified (Note that we show the accessor methods only in +this example). By defining properties we can use the name of the +attribute as method name to access the variable. . The listing below +shows an implementation of this conceptual model in NX.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + | nx::Class create C { -NX provides a generalized mechanism for passing values to either -methods (we refer to these as _method parameters_) or to objects -(these are called _object parameters_). Both kind of parameters -might have different features, such as: + # Define an ensemble method "string" with sub-methods + # "length", "tolower" and "info" + + :public method "string length" {x} {....} + :public method "string tolower" {x} {...} + :public method "string info" {x} {...} + ... + :create c1 +} -- Positional and non-positional parameters -- Required and non-required parameters -- Default values for parameters -- Value-checking for parameters -- Multiplicity of parameters - -TODO: complete list above and provide a short summary of the section - -Before we discuss method and object parameters in more detail, we +# Invoke the ensemble method +c1 string length "hello world" |
…
NX provides a generalized mechanism for passing values to either +methods (we refer to these as method parameters) or to objects +(these are called object parameters). Both kind of parameters +might have different features, such as:
+Positional and non-positional parameters +
++Required and non-required parameters +
++Default values for parameters +
++Value-checking for parameters +
++Multiplicity of parameters +
+TODO: complete list above and provide a short summary of the section
Before we discuss method and object parameters in more detail, we describe the parameter features in the subsequent sections based on -method parameters. - -==== Positional and Non-Positional Parameters - -If the position of a parameter in the list of formal arguments +method parameters.
If the position of a parameter in the list of formal arguments (e.g. passed to a function) is significant for its meaning, this is a -_positional_ parameter. If the meaning of the parameter is independent -of its postion, this is a _non-positional_ parameter. When we call a +positional parameter. If the meaning of the parameter is independent +of its postion, this is a non-positional parameter. When we call a method with positional parameters, the meaning of the parameters (the association with the argument in the argument list of the method) is determined by its position. When we call a method with non-positional parameters, their meaning is determined via a name passed with the -argument during invocation. +argument during invocation.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + | nx::Object create o1 { -[[xmp-posnonpos]] -.Listing {counter:figure-number}: Positional and Non-Positional Method Parameters -{set:xmp-posnonpos:Listing {figure-number}} -[source,tcl,numbers] --------------------------------------------------- -nx::Object create o1 { - - # - # Method foo has positional parameters: - # - :public method foo {x y} { - puts "x=$x y=$y" + # + # Method foo has positional parameters: + # + :public method foo {x y} { + puts "x=$x y=$y" } - # - # Method bar has non-positional parameters: - # - :public method bar {-x -y} { - puts "x=$x y=$y" + # + # Method bar has non-positional parameters: + # + :public method bar {-x -y} { + puts "x=$x y=$y" } - # - # Method baz has non-positional and - # positional parameters: - # - :public method baz {-x -y a} { - puts "x? [info exists x] y? [info exists y] a=$a" + # + # Method baz has non-positional and + # positional parameters: + # + :public method baz {-x -y a} { + puts "x? [info exists x] y? [info exists y] a=$a" } } -# invoke foo (positional parameters) -o1 foo 1 2 +# invoke foo (positional parameters) +o1 foo 1 2 -# invoke bar (non-positional parameters) -o1 bar -y 3 -x 1 +# invoke bar (non-positional parameters) +o1 bar -y 3 -x 1 o1 bar -x 1 -y 3 -# invoke baz (positional and non-positional parameters) -o1 baz -x 1 100 +# invoke baz (positional and non-positional parameters) +o1 baz -x 1 100 o1 baz 200 -o1 baz -- -y --------------------------------------------------- - -Consider the example in <<xmp-posnonpos, {xmp-posnonpos}>>. The method -+foo+ has the argument list +x y+. This means that the first argument -is passed in an invocation like +o1 foo 1 2+ to +x+ (here, the value -+1+), and the second argument is passed to +y+ (here the value +2+). -Method +bar+ has in contrary just with non-positional arguments. Here +o1 baz -- -y |
Consider the example in Listing 31. The method +foo has the argument list x y. This means that the first argument +is passed in an invocation like o1 foo 1 2 to x (here, the value +1), and the second argument is passed to y (here the value 2). +Method bar has in contrary just with non-positional arguments. Here we pass the names of the parameter together with the values. In the -invocation +o1 bar -y 3 -x 1+ the names of the parameters are prefixed +invocation o1 bar -y 3 -x 1 the names of the parameters are prefixed with a dash ("-"). No matter whether in which order we write the non-positional parameters in the invocation (see line 30 and 31 in -<<xmp-posnonpos, {xmp-posnonpos}>>) in both cases the variables +x+ -and +y+ in the body of the method +bar+ get the same values assigned -(+x+ becomes +1+, +y+ becomes +3+). - -It is certainly possible to combine positional and non-positional -arguments. Method +baz+ provides two non-positional parameter (+-y+ -and +-y+) and one positional parameter (namely +a+). The invocation in -line 34 passes the value of +1+ to +x+ and the value of +100+ to +a+. -There is no value passed to +y+, therefore value of +y+ will be -undefined in the body of +baz+, +info exists y+ checks for the -existence of the variable +y+ and returns +0+. - -The invocation in line 35 passes only a value to the positional +Listing 31) in both cases the variables x +and y in the body of the method bar get the same values assigned +(x becomes 1, y becomes 3).
It is certainly possible to combine positional and non-positional +arguments. Method baz provides two non-positional parameter (-y +and -y) and one positional parameter (namely a). The invocation in +line 34 passes the value of 1 to x and the value of 100 to a. +There is no value passed to y, therefore value of y will be +undefined in the body of baz, info exists y checks for the +existence of the variable y and returns 0.
The invocation in line 35 passes only a value to the positional parameter. A more tricky case is in line 36, where we want to pass -+-y+ as a value to the positional parameter +a+. The case is more -tricky since syntactically the argument parser might consider +-y+ as -the name of one of the non-positional parameter. Therefore we use +--+ +-y as a value to the positional parameter a. The case is more +tricky since syntactically the argument parser might consider -y as +the name of one of the non-positional parameter. Therefore we use -- (double dash) to indicate the end of the block of the non-positional -parameters and therefore the value of +-y+ is passed to +a+. - -==== Optional and Required Parameters - -Per default positional parameters are required, and non-positional +parameters and therefore the value of -y is passed to a.
Per default positional parameters are required, and non-positional parameters are optional (they can be left out). By using parameter options, we can as well define positional parameters, which are -optional, and non-positional parameters, which are required. +optional, and non-positional parameters, which are required.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + | nx::Object create o2 { -[[xmp-optional-req]] -.Listing {counter:figure-number}: Optional and Required Method Parameters -{set:xmp-optional-req:Listing {figure-number}} -[source,tcl,numbers] --------------------------------------------------- -nx::Object create o2 { - - # - # Method foo has one required and one optional - # positional parameter: - # - :public method foo {x:required y:optional} { - puts "x=$x y? [info exists y]" + # + # Method foo has one required and one optional + # positional parameter: + # + :public method foo {x:required y:optional} { + puts "x=$x y? [info exists y]" } - # - # Method bar has one required and one optional - # non-positional parameter: - # - :public method bar {-x:required -y:optional} { - puts "x=$x y? [info exists y]" + # + # Method bar has one required and one optional + # non-positional parameter: + # + :public method bar {-x:required -y:optional} { + puts "x=$x y? [info exists y]" } } -# invoke foo (one optional positional parameter is missing) -o2 foo 1 --------------------------------------------------- - -The example in <<xmp-optional-req, {xmp-optional-req}>> defined method +foo+ +# invoke foo (one optional positional parameter is missing) +o2 foo 1 |
The example in Listing 32 defined method foo with one required and one optional positional parameter. For this -purpose we use the parameter options +required+ and +optional+. The +purpose we use the parameter options required and optional. The parameter options are separated from the parameter name by a colon. If there are multiple parameter options, these are separated by commas -(we show this in later examples). - -The parameter definition +x:required+ for method +foo+ is equivalent -to +x+ without any parameter options (see e.g. previous example), +(we show this in later examples).
The parameter definition x:required for method foo is equivalent +to x without any parameter options (see e.g. previous example), since positional parameters are per default required. The invocation -in line 21 of <<xmp-optional-req, {xmp-optional-req}>> will lead to an -undefined variable +y+ in method +foo+, because no value us passed to +in line 21 of Listing 32 will lead to an +undefined variable y in method foo, because no value us passed to the optional parameter. Note that only trailing positional parameters might be -optional. If we would call method +foo+ of <<xmp-posnonpos, -{xmp-posnonpos}>> with only one argument, the system would raise an -exception. - -Similarly, we define method +bar+ in <<xmp-optional-req, -{xmp-optional-req}>> with one required and one optional non-positional -parameter. The parameter definition +-y:optional+ is equivalent to -+-y+, since non-positional parameter are per default optional. -However, the non-positional parameter +-x:required+ is required. If we -invoke +bar+ without it, the system will raise an exception. - -==== Default Values for Parameters - -Optional parameters might have a default value, which will be used, +optional. If we would call method foo of Listing 31 with only one argument, the system would raise an +exception.
Similarly, we define method bar in Listing 32 with one required and one optional non-positional +parameter. The parameter definition -y:optional is equivalent to +-y, since non-positional parameter are per default optional. +However, the non-positional parameter -x:required is required. If we +invoke bar without it, the system will raise an exception.
Optional parameters might have a default value, which will be used, when not value is provided for this parameter. Default values can be -specified for positional and non-positional parameters. +specified for positional and non-positional parameters.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + | nx::Object create o3 { -[[xmp-default-value]] -.Listing {counter:figure-number}: Method Parameters with Default Values -{set:xmp-default-value:Listing {figure-number}} -[source,tcl,numbers] --------------------------------------------------- -nx::Object create o3 { - - # - # Positional parameter with default value: - # - :public method foo {x:required {y 101}} { - puts "x=$x y? [info exists y]" + # + # Positional parameter with default value: + # + :public method foo {x:required {y 101}} { + puts "x=$x y? [info exists y]" } - # - # Non-positional parameter with default value: - # - :public method bar {{-x 10} {-y 20}} { - puts "x=$x y? [info exists y]" + # + # Non-positional parameter with default value: + # + :public method bar {{-x 10} {-y 20}} { + puts "x=$x y? [info exists y]" } } -# use default values -o3 foo -o3 bar --------------------------------------------------- - -In order to define a default value, the parameter specification must +# use default values +o3 foo +o3 bar |
In order to define a default value, the parameter specification must be of the form of a 2 element list, where the second argument is the default value. See for an example in -<<xmp-default-value,{xmp-default-value}>>. - -==== Value Constraints - -NX provides value constraints for all kind of parameters. By +Listing 33.
NX provides value constraints for all kind of parameters. By specifying value constraints a developer can restrict the permissible values for a parameter and document the expected values in the source code. Value checking in NX is conditional, it can be turned on or off in general or on a per-usage level (more about this later). The same mechanisms can be used not only for input value checking, but as well -for return value checking (we will address this point as well later). - -===== Built-in Value Constraints - -NX comes with a set of built-in value constraints, which can be +for return value checking (we will address this point as well later).
NX comes with a set of built-in value constraints, which can be extended on the scripting level. The built-in checkers are either the native checkers provided directly by the Next Scripting Framework (the most efficient checkers) or the value checkers provided by Tcl through -+string is ...+. The built-in checkers have as well the advantage that +string is …. The built-in checkers have as well the advantage that they can be used also at any time during bootstrap of an object system, at a time, when e.g. no objects or methods are defined. The same checkers are used as well for all C-implemented primitives of NX -and the Next Scripting Framework. - -[[img-value-checkers]] -image::value-checkers.png[align="center",title="General Applicable Value Checkers in NX"] -{set:img-value-checkers:Figure {figure-number}} - -<<img-value-checkers, {img-value-checkers}>> shows the built-in +and the Next Scripting Framework.
+Figure 34 shows the built-in general applicable value checkers available in NX, which can be used for all method and object parameters. In the next step, we show how to use these value-checkers for checking permissible values for method parameters. Then we will show, how to provide more detailed value -constraints. +constraints.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + | nx::Object create o4 { -[[xmp-value-check]] -.Listing {counter:figure-number}: Method Parameters with Value Constraints -{set:xmp-value-check:Listing {figure-number}} -[source,tcl,numbers] --------------------------------------------------- -nx::Object create o4 { - - # - # Positional parameter with value constraints: - # - :public method foo {x:integer o:object,optional} { - puts "x=$x o? [info exists o]" + # + # Positional parameter with value constraints: + # + :public method foo {x:integer o:object,optional} { + puts "x=$x o? [info exists o]" } - # - # Non-positional parameter with value constraints: - # - :public method bar {{-x:integer 10} {-verbose:boolean false}} { - puts "x=$x y=$y" + # + # Non-positional parameter with value constraints: + # + :public method bar {{-x:integer 10} {-verbose:boolean false}} { + puts "x=$x y=$y" } } -# The following invocation raises an exception -o4 foo a --------------------------------------------------- - -Value contraints are specified as parameter options in the parameter -specifications. The parameter specification +x:integer+ defines +x+ as +# The following invocation raises an exception +o4 foo a |
Value contraints are specified as parameter options in the parameter +specifications. The parameter specification x:integer defines x as a required positional parmeter which value is constraint to an -integer. The parameter specification +o:object,optional+ shows how to -combine multiple parameter options. The parameter +o+ is an optional +integer. The parameter specification o:object,optional shows how to +combine multiple parameter options. The parameter o is an optional positional parameter, its value must be an object (see -<<xmp-value-check,{xmp-value-check}>>). Value constraints are +Listing 35). Value constraints are specified exactly the same way for non-positional parameters (see -method +bar+ in <<xmp-value-check,{xmp-value-check}>>). +method bar in Listing 35).
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + | # +# Create classes for Person and Project +# +Class create Person +Class create Project -[[xmp-check-parameterized]] -.Listing {counter:figure-number}: Parameterized Value Constraints -{set:xmp-check-parameterized:Listing {figure-number}} -[source,tcl,numbers] --------------------------------------------------- -# -# Create classes for Person and Project -# -Class create Person -Class create Project - -nx::Object create o5 { - # - # Parameterized value constraints - # - :public method work { +nx::Object create o5 { + # + # Parameterized value constraints + # + :public method work { -person:object,type=Person -project:object,type=Project } { - # ... - } + # ... + } } -# -# Create a Person and a Project instance -# -Person create gustaf -Project create nx +# +# Create a Person and a Project instance +# +Person create gustaf +Project create nx -# -# Use method with value constraints -# -o5 work -person gustaf -project nx --------------------------------------------------- - -The native checkers +object+, +class+, +metaclass+ and +baseclass+ can -be further specialized with the parameter option +type+ to restrict +# +# Use method with value constraints +# +o5 work -person gustaf -project nx |
The native checkers object, class, metaclass and baseclass can +be further specialized with the parameter option type to restrict the permissible values to instances of certain classes. We can use for -example the native value constraint +object+ either for testing +example the native value constraint object either for testing whether an argument is some object (without further constraints, as in -<<xmp-default-value, {xmp-default-value}>>, method +foo+), or we can +Listing 33, method foo), or we can constrain the value further to some type (direct or indirect instance -of a class). This is shown by method +work+ in -<<xmp-check-parameterized, {xmp-check-parameterized}>> which requires -the parameter +-person+ to be an instance of class +Person+ and the -parameter +-project+ to be an instance of class +Project+. - -===== Scripted Value Constraints - -The set of predefined value checkers can be extended by application +of a class). This is shown by method work in +Listing 36 which requires +the parameter -person to be an instance of class Person and the +parameter -project to be an instance of class Project.
The set of predefined value checkers can be extended by application programs via defining methods following certain conventions. The user -defined value checkers are defined as methods of the class +nx::Slot+ +defined value checkers are defined as methods of the class nx::Slot or of one of its subclasses or instances. We will address such cases in the next sections. In the following example we define two new -value checkers on class +nx::Slot+. The first value checker is called -+groupsize+, the second one is called +choice+. - -[[xmp-user-types]] -.Listing {counter:figure-number}: Scripted Value Checker for Method Parameters -{set:xmp-user-types:Listing {figure-number}} -[source,tcl,numbers] --------------------------------------------------- -# -# Value checker named "groupsize" -# -::nx::Slot method type=groupsize {name value} { - if {$value < 1 || $value > 6} { - error "Value '$value' of parameter $name is not between 1 and 6" +value checkers on class nx::Slot. The first value checker is called +groupsize, the second one is called choice.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + 37 + 38 + 39 + 40 + | # +# Value checker named "groupsize" +# +::nx::Slot method type=groupsize {name value} { + if {$value < 1 || $value > 6} { + error "Value '$value' of parameter $name is not between 1 and 6" } } -# -# Value checker named "choice" with extra argument -# -::nx::Slot method type=choice {name value arg} { - if {$value ni [split $arg |]} { - error "Value '$value' of parameter $name not in permissible values $arg" +# +# Value checker named "choice" with extra argument +# +::nx::Slot method type=choice {name value arg} { + if {$value ni [split $arg |]} { + error "Value '$value' of parameter $name not in permissible values $arg" } } -# -# Create an application class D -# using the new value checkers -# -Class create D { - :public method foo {a:groupsize} { - # ... - } - :public method bar {a:choice,arg=red|yellow|green b:choice,arg=good|bad} { - # ... - } +# +# Create an application class D +# using the new value checkers +# +Class create D { + :public method foo {a:groupsize} { + # ... + } + :public method bar {a:choice,arg=red|yellow|green b:choice,arg=good|bad} { + # ... + } } -D create d1 +D create d1 -# testing "groupsize" -d1 foo 2 +# testing "groupsize" +d1 foo 2 d1 foo 10 -# testing "choice" -d1 bar green good -d1 bar pink bad --------------------------------------------------- - -In order to define a checker +groupsize+ a method of the name -+type=groupsize+ is defined. This method receives two arguments, -+name+ and +value+. The first argument is the name of the parameter +# testing "choice" +d1 bar green good +d1 bar pink bad |
In order to define a checker groupsize a method of the name +type=groupsize is defined. This method receives two arguments, +name and value. The first argument is the name of the parameter (mostly used for the error message) and the second parameter is provided value. The value checker simply tests whether the provided value is between 1 and 3 and raises an exception if this is not the -case (invocation in line 36 in <<xmp-user-types, {xmp-user-types}>>). - -The checker +groupsize+ has the permissible values defined in its -method's body. It is as well possible to define more generic checkers +case (invocation in line 36 in Listing 37).
The checker groupsize has the permissible values defined in its +method’s body. It is as well possible to define more generic checkers that can be parameterized. For this parameterization, one can pass an -argument to the checker method (last argument). The checker +choice+ +argument to the checker method (last argument). The checker choice can be used for restricting the values to a set of predefined constants. This set is defined in the parameter specification. The -parameter +a+ of method +bar+ in <<xmp-user-types, {xmp-user-types}>> -is restricted to the values +red+, +yellow+ or +green+, and the -parameter +b+ is restricted to +good+ or +bad+. Note that the syntax +parameter a of method bar in Listing 37 +is restricted to the values red, yellow or green, and the +parameter b is restricted to good or bad. Note that the syntax of the permissible values is solely defined by the definition of the value checker in lines 13 to 17. The invocation in line 39 will be ok, -the invocation in line 40 will raise an exception, since +pink+ is not -allowed. - -If the same checks are used in many places in the program, +the invocation in line 40 will raise an exception, since pink is not +allowed.
If the same checks are used in many places in the program, defining names for the value checker will be the better choice since it improves maintainability. For seldomly used kind of checks, the -parameterized value checkers might be more convenient. - -==== Multiplicity - -***************************************************************************** -*Multiplicity* is used to define whether a parameter should receive -single or multiple values. -***************************************************************************** - -A multiplicity specification has a lower and an upper bound. A lower -bound of +0+ means that the value might be empty. A lower bound of +1+ +parameterized value checkers might be more convenient.
A multiplicity specification has a lower and an upper bound. A lower +bound of 0 means that the value might be empty. A lower bound of 1 means that the the parameter needs at least one value. The upper bound -might be +1+ or +n+ (or synonymously +*+). While the upper bound of -+1+ states that at most one value has to be passed, the upper bound of -+n+ says that multiple values are permitted. Other kinds of -multiplicity are currently not allowed. - -The multiplicity is written as parameter option in the parameter -specification in the form _lower-bound_.._upper-bound_. If no -multiplicity is defined the default multiplicity is +1..1+, which +might be 1 or n (or synonymously *). While the upper bound of +1 states that at most one value has to be passed, the upper bound of +n says that multiple values are permitted. Other kinds of +multiplicity are currently not allowed.
The multiplicity is written as parameter option in the parameter +specification in the form lower-bound..upper-bound. If no +multiplicity is defined the default multiplicity is 1..1, which means: provide exactly one (atomic) value (this was the case in the -previous examples). +previous examples).
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + | nx::Object create o6 { -[[xmp-multiplicity]] -.Listing {counter:figure-number}: Method Parameters with Explicit Multiplicity -{set:xmp-multiplicity:Listing {figure-number}} -[source,tcl,numbers] --------------------------------------------------- -nx::Object create o6 { - - # - # Positional parameter with an possibly empty - # single value - # - :public method foo {x:integer,0..1} { - puts "x=$x" + # + # Positional parameter with an possibly empty + # single value + # + :public method foo {x:integer,0..1} { + puts "x=$x" } - # - # Positional parameter with an possibly empty - # list of values value - # - :public method bar {x:integer,0..n} { - puts "x=$x" + # + # Positional parameter with an possibly empty + # list of values value + # + :public method bar {x:integer,0..n} { + puts "x=$x" } - # - # Positional parameter with a non-empty - # list of values - # - :public method baz {x:integer,1..n} { - puts "x=$x" + # + # Positional parameter with a non-empty + # list of values + # + :public method baz {x:integer,1..n} { + puts "x=$x" } -} --------------------------------------------------- - -<<xmp-multiplicity, {xmp-multiplicity}>> contains three examples for +} |
Listing 38 contains three examples for positional parameters with different multiplicities. Multiplicity is often combined with value constraints. A parameter specification of -the form +x:integer,0..n+ means that the parameter +x+ receives a list +the form x:integer,0..n means that the parameter x receives a list of integers, which might be empty. Note that the value constraints are -applied to every single element of the list. - -The parameter specification +x:integer,0..1+ means that +x+ might be +applied to every single element of the list.
The parameter specification x:integer,0..1 means that x might be an integer or it might be empty. This is one style of specifying that no explicit value is passed for a certain parameter. Another style is to use required or optional parameters. NX does not enforce any -particular style for handling unspecified values. - -All the examples in <<xmp-multiplicity, {xmp-multiplicity}>> are for +particular style for handling unspecified values.
All the examples in Listing 38 are for single positional parameters. Certainly, multiplicity is fully orthogonal with the other parameter features and can be used as well for multiple parameters, non-positional parameter, default values, -etc. - -== Advanced Language Features - -... - -=== Objects, Classes and Meta-Classes - -... - -=== Resolution Order and Next-Path - -... - -=== Details on Method and Object Parameters - -The parameter specifications are used in NX for the following -purposes. They are used for - -- the specification of input arguments of methods and commands, for -- the specification of return values of methods and commands, and for -- the specification for the initialization of objects. - -We refer to the first two as method parameters and the last one as +etc.
…
…
…
The parameter specifications are used in NX for the following +purposes. They are used for
+the specification of input arguments of methods and commands, for +
++the specification of return values of methods and commands, and for +
++the specification for the initialization of objects. +
+We refer to the first two as method parameters and the last one as object parameters. The examples in the previous sections all parameter -specification were specifications of method parameters. - -***************************************************************************** -*Method parameters* specify properties about permissible values passed -to methods. -***************************************************************************** - -The method parameter specify how methods are invoked, how the +specification were specifications of method parameters.
The method parameter specify how methods are invoked, how the actual arguments are passed to local variables of the invoked method -and what kind of checks should be performed on these. - -***************************************************************************** -*Object parameters* are parameters that specify, with what values +and what kind of checks should be performed on these.
Syntactically, object parameters and method parameters are the same, although there are certain differences (e.g. some parameter options are only applicable for objects parameters, the list of object parameters is computed dynamically from the class structures, object parameters are often used in combination with special setter methods, etc.). Consider the following example, where we define the two -application classes +Person+ and +Student+ with a few properties. - -[[xmp-object-parameters]] -.Listing {counter:figure-number}: Object Parameters -{set:xmp-object-parameters:Listing {figure-number}} -[source,tcl,numbers] --------------------------------------------------- -# -# Define a class Person with properties "name" -# and "birthday" -# -nx::Class create Person { - :property name:required - :property birthday +application classes Person and Student with a few properties.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + | # +# Define a class Person with properties "name" +# and "birthday" +# +nx::Class create Person { + :property name:required + :property birthday } -# -# Define a class Student as specialization of Person -# with and additional property -# -nx::Class create Student -superclass Person { - :property matnr:required - :property {oncampus:boolean true} +# +# Define a class Student as specialization of Person +# with and additional property +# +nx::Class create Student -superclass Person { + :property matnr:required + :property {oncampus:boolean true} } -# -# Create instances using object parameters -# for the initialization -# -Person create p1 -name Bob -Student create s1 -name Susan -matnr 4711 +# +# Create instances using object parameters +# for the initialization +# +Person create p1 -name Bob +Student create s1 -name Susan -matnr 4711 -# Access property value via accessor method -puts "The name of s1 is [s1 name]" --------------------------------------------------- - -The class +Person+ has two properties +name+ and +birthday+, where the -property +name+ is required, the property +birthday+ is not. The -class +Student+ is a subclass of +Person+ with the additional required -property +matnr+ and an optional property +oncampus+ with the -default value +true+ (see <<xmp-object-parameters, -{xmp-object-parameters}>>). The class diagram below visualizes these -definitions. - -[[img-object-parameters]] -image::object-parameter.png[align="center",title="System and Application Classes"] -{set:img-object-parameters:Figure {figure-number}} - -In NX, these definitions imply that instances of the class of +Person+ -have the properties +name+ and +birthday+ as _non-positional object -parameters_. Furthermore it implies that instances of +Student+ will -have the object parameters of +Person+ augmented with the object -parameters from +Student+ (namely +matnr+ and +oncampus+). Based on -these object parameters, we can create a +Person+ named +Bob+ and a -+Student+ named +Susan+ with the matriculation number +4711+ (see line -23 and 24 in <<xmp-object-parameters, -{xmp-object-parameters}>>). After the object +s1+ is created it has the -instance variables +name+, +matnr+ and +oncampus+ (the latter is -initialized with the default value). - -==== Object Parameters for all NX Objects - -The object parameters are not limited to the application defined +# Access property value via accessor method +puts "The name of s1 is [s1 name]" |
The class Person has two properties name and birthday, where the +property name is required, the property birthday is not. The +class Student is a subclass of Person with the additional required +property matnr and an optional property oncampus with the +default value true (see Listing 39). The class diagram below visualizes these +definitions.
+In NX, these definitions imply that instances of the class of Person +have the properties name and birthday as non-positional object +parameters. Furthermore it implies that instances of Student will +have the object parameters of Person augmented with the object +parameters from Student (namely matnr and oncampus). Based on +these object parameters, we can create a Person named Bob and a +Student named Susan with the matriculation number 4711 (see line +23 and 24 in Listing 39). After the object s1 is created it has the +instance variables name, matnr and oncampus (the latter is +initialized with the default value).
The object parameters are not limited to the application defined properties, also NX provides some predefined definitions. Since -+Person+ is a subclass of +nx::Object+ also the object parameters of -+nx::Object+ are inherited. In the introductory stack example, we used -+-mixin+ applied to an object to denote per-object mixins (see -<<xmp-using-class-safety, {xmp-using-class-safety}>>). Since +mixin+ -is defined as a parameter on +nx::Object+ it can be used as an object -parameter +-mixin+ for all objects in NX. To put it in other words, +Person is a subclass of nx::Object also the object parameters of +nx::Object are inherited. In the introductory stack example, we used +-mixin applied to an object to denote per-object mixins (see +Listing 8). Since mixin +is defined as a parameter on nx::Object it can be used as an object +parameter -mixin for all objects in NX. To put it in other words, every object can be configured to have per-object mixins. If we would -remove this definition, this feature would be removed as well. - -As shown in the introductory examples, every object can be configured +remove this definition, this feature would be removed as well.
As shown in the introductory examples, every object can be configured via a scripted initialization block (the optional scripted block specified at object creation as last argument; see -<<xmp-object-stack, {xmp-object-stack}>> or -<<xmp-object-integer-stack, {xmp-object-integer-stack}>>). The +Listing 5 or +Listing 12). The scripted block and its meaning are as well defined by the means of object parameters. However, this object parameter is positional (last argument) and optional (it can be omitted). The following listing shows -(simplified) the object parameters of +Person p1+ and +Student s1+. - -[[xmp-object-parameter-list]] -.Listing {counter:figure-number}: Computed Actual Object Parameter (simplified) -{set:xmp-object-parameter-list:Listing {figure-number}} -[source,tcl,numbers] --------------------------------------------------- -Object parameter for Person p1: +(simplified) the object parameters of Person p1 and Student s1.
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + | Object parameter for Person p1: -name:required -birthday ... - -mixin:mixinreg,alias,1..n -filter:filterreg,alias,1..n _:initcmd,optional + -mixin:mixinreg,alias,1..n -filter:filterreg,alias,1..n _:initcmd,optional -Object parameter for Student s1: +Object parameter for Student s1: -matnr:required {-oncampus:boolean true} -name:required -birthday ... - -mixin:mixinreg,alias,1..n -filter:filterreg,alias,1..n _:initcmd,optional --------------------------------------------------- - -The actual values can be optained via introspection via +Person info -parameter definition+. The object parameter types +mixinreg+ and -+filterreg+ are for converting definitions of filters and mixins. The -object parameter type +initcmd+ says that the content of this variable + -mixin:mixinreg,alias,1..n -filter:filterreg,alias,1..n _:initcmd,optional |
The actual values can be optained via introspection via Person info +parameter definition. The object parameter types mixinreg and +filterreg are for converting definitions of filters and mixins. The +object parameter type initcmd says that the content of this variable will be executed in the context of the object being created (before -the constructor +init+ is called). More about the object parameter -types later. - -==== Object Parameters for all NX Classes - -Since classes are certain kind of objects, classes are parameterized +the constructor init is called). More about the object parameter +types later.
Since classes are certain kind of objects, classes are parameterized in the same way as objects. A typical parameter for a class definition is the relation of the class to its superclass.In our example, we have -specified, that +Student+ has +Person+ as superclass via the -non-positional object parameter +-superclass+. If no superclass is +specified, that Student has Person as superclass via the +non-positional object parameter -superclass. If no superclass is specified for a class, the default superclass is -+nx::Object+. Therefore +nx::Object+ is the default value for the -parameter +superclass+. - -Another frequently used parameter for classes is +-mixin+ to denote +nx::Object. Therefore nx::Object is the default value for the +parameter superclass.
Another frequently used parameter for classes is -mixin to denote per-class mixins (see e.g. the introductory Stack example in -<<xmp-class-safestack,{xmp-class-safestack}>>), which is defined in -the same way. - -Since +Student+ is an instance of the meta-class +nx::Class+ it -inherits the object parameters from +nx::Class+ (see class diagram -<<img-object-parameters,{img-object-parameters}>>). Therefore, one can -use e.g. +-superclass+ in the definition of classes. - -Since +nx::Class+ is a subclass of +nx::Object+, the meta-class -+nx::Class+ inherits the parameter definitions from the most general -class +nx::Object+. Therefore, every class might as well be configured +Listing 10), which is defined in +the same way.
Since Student is an instance of the meta-class nx::Class it +inherits the object parameters from nx::Class (see class diagram +Figure 40). Therefore, one can +use e.g. -superclass in the definition of classes.
Since nx::Class is a subclass of nx::Object, the meta-class +nx::Class inherits the parameter definitions from the most general +class nx::Object. Therefore, every class might as well be configured with a scripted initialization block the same way as objects can be configured. We used actually this scripted initialization block in most examples for defining the methods of the class. The following -listing shows (simplified) the parameters applicable for +Class -Student+. - -[[xmp-class-parameter-list]] -.Listing {counter:figure-number}: Computed Parameters for a Class (simplified) -{set:xmp-class-parameter-list:Listing {figure-number}} -[source,tcl,numbers] --------------------------------------------------- -Object parameter for Class Student: - -mixin:mixinreg,alias,1..n -filter:filterreg,alias,1..n ... - {-superclass:class,alias,1..n ::nx::Object} ... --------------------------------------------------- - -The actual values can be obtained via introspection via +nx::Class info -parameter definition+. - - -==== User defined Parameter Types - -More detailed definition of the object parameter types comes here. - -==== Slot Classes and Slot Objects - -In one of the previous sections, we defined scripted (application -defined) checker methods on a class named +nx::Slot+. In general NX +listing shows (simplified) the parameters applicable for Class +Student.
1 + 2 + 3 + | Object parameter for Class Student: + -mixin:mixinreg,alias,1..n -filter:filterreg,alias,1..n ... + {-superclass:class,alias,1..n ::nx::Object} ... |
The actual values can be obtained via introspection via nx::Class info +parameter definition.
More detailed definition of the object parameter types comes here.
In one of the previous sections, we defined scripted (application +defined) checker methods on a class named nx::Slot. In general NX offers the possibility to define value checkers not only for all usages of parameters but as well differently for method parameters or -object parameters - -[[img-slots]] -image::slots.png[align="center",title="Slot Classes and Objects"] -{set:img-slots:Figure {figure-number}} - - -==== Attribute Slots - - -Still Missing - -- return value checking -- switch -- initcmd ... -- subst rules -- converter -- incremental slots - -== Miscellaneous - -=== Profiling - -=== Unknown Handlers - -NX provides two kinds of unknown handlers: - -- Unknown handlers for methods -- Unknown handlers for objects and classes - -==== Unknown Handlers for Methods - -Object and classes might be equipped -with a method +unknown+ which is called in cases, where an unknown +object parameters
+Still Missing
+return value checking +
++switch +
++initcmd … +
++subst rules +
++converter +
++incremental slots +
+NX provides two kinds of unknown handlers:
+Unknown handlers for methods +
++Unknown handlers for objects and classes +
+Object and classes might be equipped +with a method unknown which is called in cases, where an unknown method is called. The method unknown receives as first argument the -called method followed by the provided arguments - -[[xmp-unknown-method]] -.Listing {counter:figure-number}: Unknown Method Handler -{set:xmp-unknown-method:Listing {figure-number}} -[source,tcl,numbers] --------------------------------------------------- -::nx::Object create o { - :method unknown {called_method args} { - puts "Unknown method '$called_method' called" +called method followed by the provided arguments
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + | ::nx::Object create o { + :method unknown {called_method args} { + puts "Unknown method '$called_method' called" } } -# Invoke an unknown method for object o: -o foo 1 2 3 +# Invoke an unknown method for object o: +o foo 1 2 3 -# Output will be: "Unknown method 'foo' called" --------------------------------------------------- - -Without any provision of an unknown method handler, an error will be -raised, when an unknown method is called. - -==== Unknown Handlers for Objects and Classes - -The next scripting framework provides in addition to unknown method +# Output will be: "Unknown method 'foo' called" |
Without any provision of an unknown method handler, an error will be +raised, when an unknown method is called.
The next scripting framework provides in addition to unknown method handlers also a means to dynamically create objects and classes, when these are referenced. This happens e.g. when superclasses, mixins, or parent objects are referenced. This mechanism can be used to implement e.g. lazy loading of these classes. Nsf allows to register multiple unknown handlers, each identified by a key (a unique name, different -from the keys of other unknown handlers). - -[[xmp-unknown-class]] -.Listing {counter:figure-number}: Unknown Class Handler -{set:xmp-unknown-class:Listing {figure-number}} -[source,tcl,numbers] --------------------------------------------------- -::nx::Class public class method __unknown {name} { - # A very simple unknown handler, showing just how - # the mechanism works. - puts "***** __unknown called with <$name>" - ::nx::Class create $name +from the keys of other unknown handlers).
1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 15 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + | ::nx::Class public class method __unknown {name} { + # A very simple unknown handler, showing just how + # the mechanism works. + puts "***** __unknown called with <$name>" + ::nx::Class create $name } -# Register an unknown handler as a method of ::nx::Class -::nsf::object::unknown::add nx {::nx::Class __unknown} +# Register an unknown handler as a method of ::nx::Class +::nsf::object::unknown::add nx {::nx::Class __unknown} -::nx::Object create o { - # The class M is unknown at this point - - :mixin add M - # The line above has triggered the unknown class handler, - # class M is now defined - - puts [:info mixin classes] - # The output will be: - # ***** __unknown called with <::M> - # ::M -} --------------------------------------------------- - -The Next Scripting Framework allows to add, query, delete and list unknown handlers. - -[[xmp-unknown-registgration]] -.Listing {counter:figure-number}: Unknown Handler registration -{set:xmp-unknown-registgration:Listing {figure-number}} -[source,tcl,numbers] --------------------------------------------------- -# Interface for unknown handlers: -# nsf::object::unknown::add /key/ /handler/ -# nsf::object::unknown::get /key/ -# nsf::object::unknown::delete /key/ -# nsf::object::unknown::keys --------------------------------------------------- - - -[bibliography] -.References - -- [[Zdun, Strembeck, Neumann 2007]] U. Zdun, M. Strembeck, G. Neumann: +::nx::Object create o { + # The class M is unknown at this point + + :mixin add M + # The line above has triggered the unknown class handler, + # class M is now defined + + puts [:info mixin classes] + # The output will be: + # ***** __unknown called with <::M> + # ::M +} |
The Next Scripting Framework allows to add, query, delete and list unknown handlers.
1 + 2 + 3 + 4 + 5 + | # Interface for unknown handlers: +# nsf::object::unknown::add /key/ /handler/ +# nsf::object::unknown::get /key/ +# nsf::object::unknown::delete /key/ +# nsf::object::unknown::keys |
+ U. Zdun, M. Strembeck, G. Neumann: Object-Based and Class-Based Composition of Transitive Mixins, Information and Software Technology, 49(8) 2007 . - -- [[Neumann and Zdun 1999a]] G. Neumann and U. Zdun: Filters as a +
++ G. Neumann and U. Zdun: Filters as a language support for design patterns in object-oriented scripting - languages. In Proceedings of COOTS'99, 5th Conference on + languages. In Proceedings of COOTS’99, 5th Conference on Object-Oriented Technologies and Systems, San Diego, May 1999. - -- [[Neumann and Zdun 1999b]] G. Neumann and U. Zdun: Implementing +
++ G. Neumann and U. Zdun: Implementing object-specific design patterns using per-object mixins. In Proc. of NOSA`99, Second Nordic Workshop on Software Architecture, Ronneby, Sweden, August 1999. - -- [[Neumann and Zdun 1999c]] G. Neumann and U. Zdun: Enhancing +
++ G. Neumann and U. Zdun: Enhancing object-based system composition through per-object mixins. In Proceedings of Asia-Pacific Software Engineering Conference (APSEC), Takamatsu, Japan, December 1999. - -- [[Neumann and Zdun 2000a]] G. Neumann and U. Zdun: XOTCL, an +
++ G. Neumann and U. Zdun: XOTCL, an object-oriented scripting language. In Proceedings of Tcl2k: The 7th USENIX Tcl/Tk Conference, Austin, Texas, February 2000. - -- [[Neumann and Zdun 2000b]] G. Neumann and U. Zdun: Towards the Usage +
++ G. Neumann and U. Zdun: Towards the Usage of Dynamic Object Aggregations as a Form of Composition In: - Proceedings of Symposium of Applied Computing (SAC'00), Como, + Proceedings of Symposium of Applied Computing (SAC’00), Como, Italy, Mar 19-21, 2000. - -- [[Neumann and Sobernig 2009]] G. Neumann, S. Sobernig: XOTcl 2.0 - A +
++ G. Neumann, S. Sobernig: XOTcl 2.0 - A Ten-Year Retrospective and Outlook, in: Proceedings of the Sixteenth Annual Tcl/Tk Conference, Portland, Oregon, October, 2009. - -- [[Ousterhout 1990]] J. K. Ousterhout: Tcl: An embeddable command +
++ J. K. Ousterhout: Tcl: An embeddable command language. In Proc. of the 1990 Winter USENIX Conference, January 1990. - -- [[Ousterhout 1998]] J. K. Ousterhout: Scripting: Higher Level +
++ J. K. Ousterhout: Scripting: Higher Level Programming for the 21st Century, IEEE Computer 31(3), March 1998. - -- [[Wetherall and Lindblad 1995]] D. Wetherall and C. J. Lindblad: Extending Tcl for +
++ D. Wetherall and C. J. Lindblad: Extending Tcl for Dynamic Object-Oriented Programming. Proc. of the Tcl/Tk Workshop '95, - July 1995. -