Index: TODO =================================================================== diff -u -r80f8424525f6c3d14ab4755be446758559f810a3 -re3a84e351aaf79c02a63cc0741dde7b9bd550849 --- TODO (.../TODO) (revision 80f8424525f6c3d14ab4755be446758559f810a3) +++ TODO (.../TODO) (revision e3a84e351aaf79c02a63cc0741dde7b9bd550849) @@ -2431,24 +2431,18 @@ - added "... info method exists ...." - updated migration guide -TODO: +- changed named of method handling commands in nsf: + ::nsf::methodproperty => ::nsf::method::property + ::nsf::method => ::nsf::method::create + ::nsf::methoddelete => ::nsf::method::delete + ::nsf::alias => ::nsf::method::alias + ::nsf::forward => ::nsf::method::forward + ::nsf::setter => ::nsf::method::setter + (updated regression test, docs, ...) -- explizites [::nsf::method delete] (sinngemäss), als ergänzung zum "{} {}"-idiom - we could extend "::nsf::method obj methodname ...." towards a - "::nsf::method create|destroy obj methodname ....", but this would - be an asymmetry for nsf::alice, nsf::forward, etc. - An option would be an ::nsf::methodelete in accoradance with methodproperty +TODO: - nsfCmd methodproperty NsfMethodPropertyCmd { - {-argName "object" -required 1 -type object} - {-argName "-per-object"} - {-argName "methodName" -required 1 -type tclobj} - -- implemented above suggestion; two more issues: - * document "nsf::methoddelete" (or find a better name for it) - * extend regression test - - fix misleading error message: nx::Class create C { :public method foo {x} {return $x} Index: doc/next-migration.html =================================================================== diff -u -r80f8424525f6c3d14ab4755be446758559f810a3 -re3a84e351aaf79c02a63cc0741dde7b9bd550849 --- doc/next-migration.html (.../next-migration.html) (revision 80f8424525f6c3d14ab4755be446758559f810a3) +++ doc/next-migration.html (.../next-migration.html) (revision e3a84e351aaf79c02a63cc0741dde7b9bd550849) @@ -1252,7 +1252,7 @@ parameters are defined (see Section 3.4).
In NX forwarders are called forward. NX does not provide an own method to define variable accessors, but uses the Next Scripting -Framework primitive nsf::setter for it.
In contrary to XOTcl, NX provides no pre-registered methods for assertion handling. All assertion handling can e performed via the -Next Scripting primitive nsf::assertion.
@@ -5731,7 +5731,7 @@
.nx-placeholder {color: #AF663F; font-weight: normal; font-style: italic;}
.nx-variable {color: #AF663F; font-weight: normal; font-style: normal;}
- ::nsf::assertion /obj/ check |
+
@@ -5757,7 +5757,7 @@
.nx-placeholder {color: #AF663F; font-weight: normal; font-style: italic;}
.nx-variable {color: #AF663F; font-weight: normal; font-style: normal;}
- ::nsf::assertion /obj/ object-invar /conditions/ |
+
@@ -5783,7 +5783,7 @@
.nx-placeholder {color: #AF663F; font-weight: normal; font-style: italic;}
.nx-variable {color: #AF663F; font-weight: normal; font-style: normal;}
- ::nsf::assertion /obj/ object-invar |
+
@@ -5809,7 +5809,7 @@
.nx-placeholder {color: #AF663F; font-weight: normal; font-style: italic;}
.nx-variable {color: #AF663F; font-weight: normal; font-style: normal;}
- ::nsf::assertion /cls/ class-invar /conditions/ |
+
@@ -5835,7 +5835,7 @@
.nx-placeholder {color: #AF663F; font-weight: normal; font-style: italic;}
.nx-variable {color: #AF663F; font-weight: normal; font-style: normal;}
- ::nsf::assertion /cls/ class-invar |
+
@@ -5861,7 +5861,7 @@
.nx-placeholder {color: #AF663F; font-weight: normal; font-style: italic;}
.nx-variable {color: #AF663F; font-weight: normal; font-style: normal;}
- ::nsf::assertion /cls/ object-invar /conditions/ |
+
@@ -5887,7 +5887,7 @@
.nx-placeholder {color: #AF663F; font-weight: normal; font-style: italic;}
.nx-variable {color: #AF663F; font-weight: normal; font-style: normal;}
- ::nsf::assertion /cls/ object-invar |
+
Since the Next Scripting Framework supports the so-called ensemble -objects, which ease the definition of sub-methods substantially, +
Since the Next Scripting Framework supports the so-called ensemble +objects, which ease the definition of sub-methods substantially, objects registered as methods have different semantics. In XOTcl 1, it was possible to call e.g. a method foo of the slot object Foo::slot::ints via the following two interfaces the same way:
Parameter-classes were rarely used and have been replaced by the more general object parameterization. Therefore, cl info parameterclass has been removed.