On Aug 9, 2017, at 2:00 PM,David Adams wrote: > Thanks for saying this so clearly. This is the reality that is behind my > feature request(s) for a set of native tools to deal with arbitrary JSON > input/output. For now, I've got NTK but it is a feature set that any modern > tool should have out of the box.
When I read all these messages about how 4D has done a “half-assed” job of implementing native support for JSON it reminds me of object properties on forms. So many times in the past, and even still today, 4D will add a now property to a form object that can only be set by using the Property List in the Design environment. So no programatic way to “set” or “get” the new property. Glaring example of this are new listbox properties. Then after some time and several new versions of 4D, new “get” and “set” commands are added to the language so you have programatic control over the property. I think JSON support has been implemented in a similar way. Instead of “full support” for JSON we have “half-assed” support. Maybe that is to sever. Maybe it more like "3/4-assed". :) But I’m confident that in future versions of 4D they will add more commands to the language and complete support for JSON. For now we will all have to work around 4D’s limitations. Also consider the constant “Folder separator”. Since the beginning of time every 4D developer has had to implement this feature using an interprocess variable or a function to return either “:” or “/“. Now we don’t need to. 4D has provided native support for this feature. Tim ******************************************** Tim Nevels Innovative Solutions 785-749-3444 [email protected] ******************************************** ********************************************************************** 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] **********************************************************************
