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 

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 Nevels
Innovative Solutions

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:4d_tech-unsubscr...@lists.4d.com

Reply via email to