Index: TODO =================================================================== diff -u -rc417409d8e77b24b3cb2a8966423452295ed68d8 -r6ad766595b0095a72fb7b3a1d6d34960a013b464 --- TODO (.../TODO) (revision c417409d8e77b24b3cb2a8966423452295ed68d8) +++ TODO (.../TODO) (revision 6ad766595b0095a72fb7b3a1d6d34960a013b464) @@ -5108,117 +5108,19 @@ Makefile: - fix load paths for sublibs (e.g. mongodb) in regression test +nsf.c: +- added nsf::var::get and "::nx::var get" to provide selector + based interface for variable reading (used in slotmethod get + of nx::VariableSlot) ======================================================================== TODO: - TODO: rename "slotassign" to "slotset"? - TODO: update tutorial and migration guide - why is there no pos/index arg for mixin|filter delete? -- finish nx-property reform +- finish nx-property reform (merge into master) -- -incremental: setting incremental will promote a property/variable - from a non-multivalued one to a multivalued one -> - i.e., it becomes 0..* unconditionally - - if the following is stated (ambiguous, but allowed): - - /obj/ object property -incremental a:1..1 - - we will end up with "a" becoming 0..*, allowing empty strings without - this being acknowledged by the definition (even if ambiguous). maybe this is more compelling when - setting incremental a posteriori and reconfigure a property/variable. - - suggestion: make the lower bound always respected -> 1..1 becomes - 1..*, 0..1 becomes 0..* - - alternatively, we can enforce that -incremental can only be used on - props/vars explicitly declared multivalued, rather than promoting - them silently? - - >>> - Maybe limiting -incremental to props/vars explicitly declared - multivalued would be more honest, simply because 0..1/1..1 permit - values (any Tcl word) which cannot be turned in to a list rep no - way ... so silently attempting to promote them will always have NX - throw up. - -- at this point, the documentation of variable vs. property (in the - man pages and the tutorial) boils down to: - - "property equals variable despite a different default value of - nonpos arg -configurable" (and the consequences entailed by this - condition -> configure option, slot object). - - (agreed, they also differ slightly by their definition syntaxes, - e.g. placement of the default value etc., but this is also more a - historical artifact) - - historically, there used to be more differences (no accessors for - variable etc.), right now, the largest portions of the their - documentation is identical. - - so, I act as the devil's advocate: is it worth keeping both, rather - than giving an example of how to use -configurable on - property to achieve what is now achieved by variable (or vice versa)? - - one could restate anything written in Section 3.1.2 of the tutorial - by substituting occurrences of ":variable" for ":property - -configurable false ...". Or, if the notion of variable should take - precedence (with the sections being named "non-configurable instance variables" - ...) drop property and keep ":variable -configurable false" which - literally expressed what is stated in the section headings. - - or, to be on the safe side, make "property" a requirable feature and - just keep "variable" for the core API? - - maybe I am wrong, if so, what is a convincing statement/scenario - (from the API perspective) to give to the reader of property - vs. variable rather than explaining property vs. property - -configurable false (or variable vs. variable -configurable false) - only? (apparently, i can't think of one) - -- incremental: should we add a third operation? - - /obj/ /prop/ get /index/ - - right now, we only provide a setter facade (add, delete) for list - values, no getter one. Reasons: consistency (per-element getter + - setter), a complete getter+setter facade would also allow for - switching from a list representation of multivalued values to - another one (e.g., some mongodb data structure?) without changing - clients of the incremental interface (e.g., which now use [lindex] - etc. to retrieve elements from the property-managed list value) ... - - get would behave like (=be implemented with) lindex. - - >>> - * the typical idiom for set-valued db-results is foreach, not lindex. - Is there a convincing use case? from databases one gets a "set" of values - accessing the nth one is rather a border case. - * We have for variable and relation slots aleady "assign", "get", - "add" and "delete", so "get" is not reasonable naming choice. - * The slot interface is extensible. different slot methods of choice can be added via - packages. so why bloat the implementation? - - >>> (adding discussion item from yesterday) - - * using the argument arity for the conditional dispatch behind the - incremental interface leads to the situation that "get" cannot - be called directly, other than assign, get, and delete. there is - no warning raised, no feedback given to the client. - * therefore, should we provide for three modes (as an example): - - - implicit slot interface (arity-based conditional dispatch), - allows for refining the slot interface "behind the scenes"- - - explicit slot interface: assign + get are "exported" to - clients = must be used. there is no convenience way of - getting/setting a property/variable (implementation using ensembles). - - incremental slot interface: implies explicit and adds "add" + - "delete" (downside: every client must use the explicit - interface: assign, get, add, delete; upside: no ambiguities - such as with get) - - check deactivated tests in tests/serialize.test C(One), C(IgnoreAll), C(None2) and xlloc fix