John, Thanks for writing back. I've looked at your post, had another try and am not sure if I can say this in a family-friendly way. But, eh? It seems impossible to determine the type of an array stored in a 4D "object" using native 4D commands. Full stop. If that's true, I have to say that I'm a bit dumbfounded. If you need to know the internals of an object in order to use it in all cases, that makes a whole world of sensible programming strategies impossible to implement. I guess that you can add your own meta-data, but it strikes me as a peculiar contraint. I'm still hoping that I'm missing something obvious, so anyone that wants to embarrass me with the details - please do!
As far as I can tell, 4D can store a wide range of data types in an "object" container. As Rob pointed out, internally this is a hash table. As far as I can find, the internals aren't described anywhere. When JPR was offering to explain things this week, I asked specifically about this point, but he doesn't seem to have had time to respond. In any case, the internal storage format and the text version that we can get are different things. So, we've got "object" values and one serialization available as a particular bit of JSON. So, when looking at what to use and how to use it, it makes sense to look both at the Object (Language) and JSON sections of the language. As best as I can determine, something is missing and has been all along. (This is what John confirms in his reply.) A summary of what I think I'm seeing - corrections and additions welcomed: * 4D an store several simple types as well as arrays in an "object." It can also store objects and arrays of objects. * The only ways to get data out of an object are OB Get: Only for simple types, including objects. OB GET ARRAY: Only for arrays. * Several meta-data functions are provided, the relevant ones being: OB GET PROPERTY NAMES OB Get type OB Is defined The "type" reference here calls all arrays "Object Array", even if they're longints or whatever * 4D obviously has the typing information internally. This is clear from how nicely (when that's what you want) it does coercion and handles pointers. Likewise, that really excellent hierarchical list display interface in the debugger clearly has access to the data types. Again, I've got zero information on how the data is stored internally, but however it's done, there's plenty of detail in there to support what 4D does and I'd like to be able to do. * You _cannot_ generate an error by trying extract an array and push it into an array of a different type. 4D tries to coerce the data as best as it can. I can see where this is a benefit, but it doesn't report this situation in any way and doesn't always do helpful coercion. For example, longint-to-object gets you an array without the stored numbers. Object-to-text gets you a bunch of text array elements with [object][object] instead of the JSON version of the object array element. So, you can't figure out that you converted the array incorrectly, can't figure out what the array should be, and may well get total garbage *unintentionally and without any error.* That strikes me as bad. * Okay, so let's go old-school and deal with the JSON itself directly. Why not? Stringy and walk through the JSON tree. JSON is always a tree structure and tree walks are a pretty bread-and-butter programming exercise. You can't. There are no JSON traversal commands native in 4D. T * Okay, then let's just get the JSON string version of the array by itself, look at the format, and figure out the array type from there. Shouldn't be too hard (perhaps, except, for pointers.) JSON syntax is pretty easy to follow. You can't. There's no way to get just the array as a JSON string. At least, I haven't come up with one. Has anyone? The only option I can see for reading an object generically is to * Stringify * Parse the full XML tree with custom code (not happening) or NTK. * Walk the tree. At that point, you're either doing way to much work or not using 4D. Okay, this is the part where people embarrass me by telling me the obvious solution(s) I've overlooked. Please do! If not, here are some ideas about what's needed: * Make OB GET PROPERTY NAMES return the stored array's actual type. * Make JSON Stringify (or similar) * Add OB GET ARRAY AS JSON and make it work with the existing JSON array/string commands. * Add in normal tree-walking utilities for the JSON tree. Right now, the JSON stuff only takes a JSON string - you can't hand in an object reference. It would be nice to get normal node references, as an option. The object and JSON commands are great features, but it really puzzles me that the seem incomplete...and seemingly avoiding access to the underlying tree structure of the JSON. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
