Metakit does not necessarily respect the case of property names in the result of [mk::get ...]. Notice the case of properties as input in lines 3, 4, and 9, and how it is output in the results of lines 6 and 11.
(Aric) 1 % package require Mk4tcl
2.4.9.7
(Aric) 2 % mk::file open test
test
(Aric) 3 % mk::view layout test.view1 {Prop1 Prop2}
test.view1
(Aric) 4 % mk::view layout test.view2 {prop1 prop3}
test.view2
(Aric) 5 % mk::row append test.view2 prop1 "some value" prop3 "some other value"
test.view2!0
(Aric) 6 % mk::get test.view2!0
Prop1 {some value} prop3 {some other value}
(Aric) 7 % mk::file close test
test
(Aric) 8 % mk::file open temp
temp
(Aric) 9 % mk::view layout temp.values {prop1 prop2 Prop3}
temp.values
(Aric) 10 % mk::row append temp.values prop1 "data" prop2 "more data" Prop3 "even more data"
temp.values!0
(Aric) 11 % mk::get temp.values!0
Prop1 data Prop2 {more data} prop3 {even more data}
(Aric) 12 % info patchlevel
8.5.1
(Aric) 13 % package require ActiveTcl
8.5.1.0.284069
(Aric) 14 % parray tcl_platform
tcl_platform(byteOrder) = littleEndian
tcl_platform(machine) = intel
tcl_platform(os) = Windows NT
tcl_platform(osVersion) = 5.1
tcl_platform(platform) = windows
tcl_platform(pointerSize) = 4
tcl_platform(threaded) = 1
tcl_platform(user) = Aric
tcl_platform(wordSize) = 4
I don't mind if Metakit wants to treat properties in a case-insensitive way on input, but on output it should return property names in their original form; it shouldn't confuse Prop1 of view1 with prop1 of view2, or (even worse) with prop1 in a subsequent Metakit file I might open. The reason it's a problem is that Tcl is case sensitive; if I use the result of [mk::get ...] to set an array, I can't guarantee that the keys in the array will be in the form I need them to be in.
- 2008-03-05 Aric Bills
Created
- 2008-03-10 jcw
For reasons of performance, there is a single global property hash table. All property names are translated to unique integers, which are then used everywhere inside MK. In hindsight, I agree - property names should be treated as case sensitive, but it's not possible to change this now without breaking a lot of existing code. What you're asking is case-preservation, but that cannot be bolted on, the string key in the hash table is the first one that gets used.
A very ugly workaround would be to create an in-memory db, and to then define some dummy view with the properties/types you're about to use in the precise case you want to see them back later. Once present in the hash table, they will then stay as "primed" by this trick. I haven't tested it, though.
- 2008-03-10 jcw
(Changed: stat)
- 2008-03-26 Aric Bills
Given that case is preserved in view layouts, I assumed those could be consulted prior to returning results with mk::get. But no worries; the easy workaround is to call mk::get with specific property names, which I am happy to do.