Change Details

It appears we lack a common understanding of where local and global keys can appropriately occur, and also lack code consistency in the support for local and global keys. This can cause unexpected bugs and time spent diagnosing and fixing them. It can also require time for each developer to investigate and understand what needs to be supported. We need greater clarity and precise documentation about this. **Illustration**: Recently it was necessary to modify a front end JavaScript utility (getValueFromCanonicalZMap) that handles ZTypedPair instances, so as to allow for either local ("K1" and "K2") or global ("Z882K1" and "Z882K2") keys. (I'm referring to the keys for "first element" and "second element", not keys that are used inside the Z1K1.) The ZPair type processed by this utility is transient, not persistent. This quote from function model page indicates that a local key is appropriate in this setting: "The main use case for Local Keys is when a Z8/Function or Z4/Type is being created on the fly, and thus cannot have Global Keys because the created Z8/Function or Z4/Type itself is not persistent." It was also necessary to do new work on ZObjectFactory::create() because it expected global keys. Currently, it still changes a local key in the input (which was placed there by the orchestrator, and is appropriately local) to a global key in its output, at least in some cases. Let's consider whether that behavior should change. **Questions**: Should we move away from this ambiguity, so that eventually we only need to support local keys in this situation? More generally, should we have a completely unique canonical form for each ZObject, or allow for certain variants in the canonical form? See also: [[ https://phabricator.wikimedia.org/T313880 | T313880 ]] and its patches. Note: regarding getValueFromCanonicalZMap, it's also present in function-schemata, and currently only supports local keys. It's my impression that function-schemata functions generally support less variation with respect to local versus global keys. Note: See also engineering meeting notes for August 4, 2022.

It appears we lack a common understanding of where local and global keys can appropriately occur, and also lack code consistency in the support for local and global keys. This can cause unexpected bugs and time spent diagnosing and fixing them. It can also require time for each developer to investigate and understand what needs to be supported. We need greater clarity and precise documentation about this. **Illustration**: Recently it was necessary to modify a front end JavaScript utility (getValueFromCanonicalZMap) that handles ZTypedPair instances, so as to allow for either local (//K1// and //K2//) or global (//Z882K1// and //Z882K2//) keys. (I'm referring to the keys for "first element" and "second element", not keys that are used inside the Z1K1.) The ZPair type processed by this utility is transient, not persistent. This quote from function model page indicates that a local key is appropriate in this setting: "The main use case for Local Keys is when a Z8/Function or Z4/Type is being created on the fly, and thus cannot have Global Keys because the created Z8/Function or Z4/Type itself is not persistent." It was also necessary to do new work on ZObjectFactory::create() because it expected global keys. Currently, it still changes local keys in the input (//K1// and //K2//, which were placed there by the orchestrator, and are appropriately local) to global keys in its output (//Z882K1// and //Z882K2//), at least in some cases. Let's consider whether that behavior should change. **Questions**: Should we move away from this ambiguity, so that eventually we only need to support local keys in this situation? More generally, should we have a completely unique canonical form for each ZObject, or allow for certain variants in the canonical form? See also: [[ https://phabricator.wikimedia.org/T313880 | T313880 ]] and its patches. Note: regarding getValueFromCanonicalZMap, it's also present in function-schemata, and currently only supports local keys. It's my impression that function-schemata functions generally support less variation with respect to local versus global keys. Note: See also engineering meeting notes for August 4, 2022.

It appears we lack a common understanding of where local and global keys can appropriately occur, and also lack code consistency in the support for local and global keys. This can cause unexpected bugs and time spent diagnosing and fixing them. It can also require time for each developer to investigate and understand what needs to be supported. We need greater clarity and precise documentation about this. **Illustration**: Recently it was necessary to modify a front end JavaScript utility (getValueFromCanonicalZMap) that handles ZTypedPair instances, so as to allow for either local ("K1"//K1// and "K2"//K2//) or global ("//Z882K1"// and "//Z882K2"//) keys. (I'm referring to the keys for "first element" and "second element", not keys that are used inside the Z1K1.) The ZPair type processed by this utility is transient, not persistent. This quote from function model page indicates that a local key is appropriate in this setting: "The main use case for Local Keys is when a Z8/Function or Z4/Type is being created on the fly, and thus cannot have Global Keys because the created Z8/Function or Z4/Type itself is not persistent." It was also necessary to do new work on ZObjectFactory::create() because it expected global keys. Currently, it still changes a local keys in the input (//K1// and //K2//, which wasere placed there by the orchestrator, and isare appropriately local) to a global keys in its output (//Z882K1// and //Z882K2//), at least in some cases. Let's consider whether that behavior should change. **Questions**: Should we move away from this ambiguity, so that eventually we only need to support local keys in this situation? More generally, should we have a completely unique canonical form for each ZObject, or allow for certain variants in the canonical form? See also: [[ https://phabricator.wikimedia.org/T313880 | T313880 ]] and its patches. Note: regarding getValueFromCanonicalZMap, it's also present in function-schemata, and currently only supports local keys. It's my impression that function-schemata functions generally support less variation with respect to local versus global keys. Note: See also engineering meeting notes for August 4, 2022.