Index: TODO =================================================================== diff -u -r216b4dd29425d7f4307b94ee8cd428a5dd7a361e -r1c770abc23851d575aa3e1c28ee07d0653147d01 --- TODO (.../TODO) (revision 216b4dd29425d7f4307b94ee8cd428a5dd7a361e) +++ TODO (.../TODO) (revision 1c770abc23851d575aa3e1c28ee07d0653147d01) @@ -4524,18 +4524,62 @@ method properties not handled as well (as the "returns" method property before the recent fix) -- Check the following todos such as "todo: don't hard-code registering - command name "method" / NSF_METHOD"; parts of the introspection - machinery in NSF rely on NX/script-level specifics ... how should we - handle this? For the system methods (create, ...), we can resolve - the situation; for the NX or XOTcl method delegates (method) of - ::nsf::method::create & friends, we do not have any - abstraction/handle right now ... should we script those info - subcmds (info method definition), against a performance penalty? +Stefan: API-related items -- __WIN32__ builds/MinGW: It seems that the http.test cases for XOTcl2 - fail against Tcl 8.6b2. Check this ... + * the introspection interface uses "-type" for "class" or "instanceof", but the intercession interface refers to "-class", e.g. + + introspection: + /obj/ info children ?-type /class/? ?/pattern/? + ... + + intercession: + + /cls/ property ?-accessor /value/? ?-config /boolean/? ?-incremental? ?-class /value/? /spec/ ?/initblock/? + + better: + + /cls/ property ?-accessor /value/? ?-config /boolean/? ?-incremental? ?-type /class/? /spec/ ?/initblock/? + + * naming: application vs. baseclasses -> applicationclasses + vs. baseclasses ... + + /obj/ info lookup methods ?-callprotection all|public|protected|private? ?-incontext? ?-methodtype all|scripted|builtin|alias|forwarder|object|setter|nsfproc? ?-nomixins? ?-path? ?-source all|application|baseclasses? ?/pattern/? + + better: + +/obj/ info lookup methods ?-callprotection all|public|protected|private? ?-incontext? ?-methodtype all|scripted|builtin|alias|forwarder|object|setter|nsfproc? ?-nomixins? ?-path? ?-source all|applicationclasses|baseclasses? ?/pattern/? + + should be consistent, either way. + + or: + + -class all|application|base + -classes all|application|base + + * - naming in slots: "incremental", "reconfigure" + + * Currently, in NX, specifying mandatory parameters may break + object construction as init won't receive any arguments (no + residual args). Similarly, a -returns might scream out. Shall we + package that by not "allowing" (actually advertising) an + argument spec block for init, e.g.: + + Class create C { + :constructor { + # ... + } + } + + ... alternative name: "initializer", or "initialize" ... which + translates into a "o method init {} {}" + + * info configure parameters & friends report ?__initcmd?, in + other context this parameter is called initblock -> property, + variable. + +== + - make rough comparison table with NX, XOTcl, tclOO, itcl, Ruby, Python Most general superclass Metaclass @@ -4560,58 +4604,14 @@ but wich are not ones (-1, "- a b c", ....) in detection when to throw unknown. - - naming of slot classes - * should we switch from "-class" to "-slotclass"? - - o1 property ?-class value? ?-incremental? ?-nocomplain? spec ?initblock? - o1 variable ?-accessor? ?-class value? ?-incremental? ?-initblock value? ?-nocomplain? spec ?value? - - * the introspection interface uses "-type", meaning "class or subclass" - - o1 info lookup slots ?-type value? ?-source value? ?pattern? - o1 info properties ?-type value? ?-closure? ?-source value? ?pattern? - o1 info slot definition ?-type value? ?-closure? ?-source value? ?pattern? - o1 info slot name ?-type value? ?-closure? ?-source value? ?pattern? - o1 info slot objects ?-type value? ?pattern? - - o1 info children ?-type class? ?pattern? - - interface of "variable" and "attribute": * add switch -array for "variable"? (Just setting is trivial, handling setters and incremental setter is more work) - handle cases, where defaultmethods of the slot are altered. The parameter handling in nx assumes on several places that - the defaultmethods are {get assign}. + the defaultm -- Revise call-stack introspection/intercession, i.e., [current - activelevel] vs. [current callinglevel] vs. uplevel()/upvar(): - - Currently, there are some inconsistencies when comparing activelevel - and callinglevel: - - 1. Both skip INACTIVE frames: This has implications for the notion - of an "activelevel" introspection as such (especially when comparing - with their semantics in XOTcl 1.*); also, we cannot access INACTIVE - (mixin, filter) frames anymore using uplevel|upvar (whether this is - needed is another issue, but at least, this breaks XOTcl 1.* - semantics, as callinglevel resolved to such INACTIVE frame contexts). - 2. The uplevel()/upvar() methods default to uplevel+callinglevel - semantics, so they borrow their issues from 1) - 3. For now, we do not support call-stack transparent up-leveling into - non-NSF frames, such as Tcl namespace + proc (apply) frames. - - Approaches: - a) Revise the current [current] subcmd scheme: callinglevel - vs. activelevel vs. ...? - b) Provide a more generic, filter-based [current callinglevel] (?) - subcmd which allows for applying different bitmask filters - c) Provide the necessary call-stack info in [info frame] and make - replacements for [current activelevel] & [current callinglevel] - scriptable ... - d) support for out/inout argument parsing strategies (however, this - would rather replace [upvar], what about [uplevel] indirection?) - - extend mongo::gridfs::store_file with a switch -metadata to pass metadata together at gridfs file creation time @@ -4663,7 +4663,6 @@ - get rid of eager tcd creation (optimization, can go to future releases) - slotmachinerie 2 - - naming "incremental", "reconfigure" - should we deactivate add/delete for non-multivalued cases? - allow noarg+default/initcmd ? - default/initcmd/subsdefault: can we simplify these? @@ -4672,33 +4671,13 @@ - Makefile/::nsf::config: Integrate git meta-data (commit hash, branch/tag labels) - doc: - - * info parametersyntax reports ?__initcmd? - - * I might have missed sth., but there is an Object->class - parameter again. I thought we had removed this one ... :$ - + * no-accessor properties/slots are still reported as methods: class * method parameters need indentation ... * method ensembles are reported as "Implementation details: alias", is this ok? - * Currently, in NX, specifying mandatory parameters may break - object construction as init won't receive any arguments (no - residual args). Similarly, a -returns might scream out. Shall we - package that by not "allowing" (actually advertising) an - argument spec block for init, e.g.: - - Class create C { - :constructor { - # ... - } - } - - ... alternative name: "initializer", or "initialize" ... which - translates into a "o method init {} {}" - * doc validator reports wierd info submethods: info definition, info names, info objects -> mean "info slot *" ... smells like generator garbage ... @@ -4712,9 +4691,6 @@ performed: See the case for "info properties" -> "info slot definition" - * naming: application vs. baseclasses -> applicationclasses - vs. baseclasses ... - * "info method": elaborate on the options, right now the doc is minimal ... @@ -4723,23 +4699,16 @@ * fix sub methods validation reporting -> mismatch? - * onerror? not used in the forward implementation ... why? earlybinding really gone? - * Ensemble methods: obj info & friends ... there is no parametersyntax reported; add something literal in the template: ? - * C method foo {} {}; # deletes "foo" without existing method, the - error message is somehow swallowed ... - * Object|Class mixin|filter guard -> how to document (and not reported by nxdoc as missing either, as their as slot-specific)? And link to Class class filterguard|mixinguard ... Why not defining the latter as ensembles "Class class filter|mixin guard"? - * Why is there no -order on "Class info filter methods"? - * Ensemble methods, i.e. intermediate ones, should not be filter by inheritance in the nxdoc output. For example, info() in Class shares many details of info in Object, but it does not visualize @@ -4858,6 +4827,15 @@ For future releases (after first alpha/beta release) + - Stefan: Still valid, IMHO: todo: don't hard-code registering + command name "method" / NSF_METHOD"; parts of the introspection + machinery in NSF rely on NX/script-level specifics ... how should we + handle this? For the system methods (create, ...), we can resolve + the situation; for the NX or XOTcl method delegates (method) of + ::nsf::method::create & friends, we do not have any + abstraction/handle right now ... should we script those info + subcmds (info method definition), against a performance penalty? + * Consider alternate method name/place for subcmds (and/or slots) on classes - currently, there are potential conflicts between slots and ensemble objects - provide a different place in the namesspaces could simplify this