David, On Tue, Jan 10, 2017 at 10:01 PM, David Adams <[email protected]> wrote:
> 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 con > s > traint. I think we were having a very similar discussion 2 or 3 years ago about this very point. To me this is a manifestation of the differences in the way javascript handles variables, because that's what a JSON is at its core, and the way 4D does. In 4D-land all the data are typed, the variables are typed and the structures are good looking. In JS-land it's more like the Castro during the Halloween party. (That last one may be a little obscure but you probably get the point.) I don't think there's a problem with the way 4D is making JSON available within 4D so much as coming at it from a 4D perspective and expecting the data object, the JSON, to tell us everything we need to know about itself. I've found JSON pretty easy to grasp since I first came on it. My usage wasn't always the most sophisticated but I got what was going on: "JSON is a lightweight data-interchange format ... [it is a] text format that is completely language independent but uses conventions that are familiar to programmers..." Being text based means pretty much anything can be there and it's up to me what I'm going to do with it and, therefor, how to type it. In 4D-land we're a bit of control freaks. Even JPR gave a nod to this referencing the deal about not wanting to publish too much detail about the internal workings lest we start expecting those things to be immutable instead of the results being consistent. JSON doesn't lend itself to that level of control so well. The 4D implementation of JSON, the c-object, has more structure than native JSON which is good when we're working in 4D but really is a 4D thing. I think we expect too much from a JSON/c-object when we want it to explain itself to such a degree. JSON is just the messenger, just a bucket of data in text format and a c-object is that data dressed up in nicer clothes. Personally I just don't run into issues of data typing or access using them and some of my uses of c-objects are getting pretty involved and extended. When I need to access something I know what level it's on or generally where it's supposed to be so the question becomes is it there or not. But like I said, in 4D I look at c-objects as agnostic data containers. So an object array being able to contain multiple data types is a feature. But I may be thinking too small. What are some cases where "you need to know the internals of an object in order to use it in all cases"? -- Kirk Brooks San Francisco, CA ======================= ********************************************************************** 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] **********************************************************************
