On Apr 30, 2012, at 3:44 PM, Richard Gaskin wrote: > While worth revising at first opportunity, to date I don't recall it being > reported as an issue here or in the forums.
I have brought this up every two or three years for a long time. Perhaps it is listed as an enhancement request. Perhaps, I am the only one who sees this as a flaw. I am not advocating doing away with arrays. I am advocating doing them right. This "feature" (bug) should have been fixed before arrayEncode() was created, immediately before if not well before. I'm sure it is possible to create new arrayEncode and ArrayDecode that work for old values generated by arrayEncode() and handle NUL. LiveCode should be as simple and as clean as possible. We have the world getting complicated around us and it we need an anchor in Livecode where concepts are unified and kept simple but rich and powerful. Also, LiveCode should be low anxiety. If there is a hole in arrays, were are there also holes? If NUL breaks things here, do they break sorting, too? A programmer does not know until he does the tests. I ask people, do you know? What else breaks with NUL? One should not have to experiment to find out the meaning of a language element. Sure, it can be documented. Every time a caveat sentence has to be added to complete documentation, the language erodes. NUL terminated strings in the externals interface have been a pain for externals programming since the beginning and many have complained about that. The iOS externals interface, even though lacking some traditional features, is much superior to the traditional desktop externals interface. I'm not advocating doing away with externals or even the traditional interface, I'm just suggesting that these issues be addressed. Dar _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
