Re: JSON Tools Was: Re: C-objects and memory use

[Rick Hazey via 4D_Tech]

First, let me say I wasn’t knocking 4D but answering the question Kirk Brooks 
asked: "At the risk of appearing really dense what are the specific things you 
can
do with NTK that you can't do with native 4D?”.  My answer is that JSON isn’t 
fully supported and I gave an example, so I’m not sure what the fuss is about. 

It seems to me JSON could be natively supported and the new collection type 
appears to be getting 4D closer to native tools for JSON. This is a good thing, 
IMHO.

I’ve been out of the 4D development game for a few years now but I still use 4D 
on a regular basis. I would love to see native JSON commands in 4D but I’ve 
rolled my own parser and key/value storage. This has worked quite well for me 
but if 4D provided native tools, I would switch to those in a heartbeat.

Perhaps turning this around, might be more enlightening: How many people would 
be interested in downloading a JSON parser if I uploaded it to github?



Rick Hazey 
Octet Industries, LLC 
--- 
r...@octethosting.net  
--- 
WWKD?

> On Aug 8, 2017, at 9:50 PM, David Adams via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> On Tue, Aug 8, 2017 at 5:14 PM, Keisuke Miyako via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
> 
>> it seems this view just keeps coming up...
>> 
> 
> 
>> I am sorry if the documentation or marketing material or presentation or
>> some other form of communication gave the wrong impression, but Object and
>> Array Object are not "4D's way of supporting JSON".
>> 
> 
> 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.
> **
> 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
> **

**
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
**

Re: JSON Tools Was: Re: C-objects and memory use

[Cannon Smith via 4D_Tech]

I can! :-)



--
Cannon.Smith
Synergy Farm Solutions Inc.
Hill Spring, AB Canada
403-626-3236




> On Aug 9, 2017, at 1:34 PM, David Adams via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> Sorry, I don't have a Forum link to the right request, but perhaps someone
> else can supply one?

**
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
**

Re: JSON Tools Was: Re: C-objects and memory use

[David Adams via 4D_Tech]

> 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.

Good point! My favorite feature request in the past year comes from Cannon
Smith and relates to your point. Cannon asked for each form object to have
a C_OBJECT associated with it *autoamtically*. The idea is to have a little
dictionary available automatically. It's a really beautiful idea nd feels
very "4D" to me. Well, if 4D were to add this feature, it would help make
it easy to store configuration/behavioral informational object about a form
widget "in" the form widget.

And, at that point, why not extend the sytax to support native 4D
properties as well?

$font_size := MyWonderfulButton.FontSize

MyWonderfulButton.FontSize := 14

If you haven't already voted for Cannon's request, please do. (Anyone
rolling their own event cycles/MVVC/etc. stuff in native 4D alredy knows
they want this...everyone else would just wonder how they had lived without
it for so long.)

Sorry, I don't have a Forum link to the right request, but perhaps someone
else can supply one?
**
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
**

Re: JSON Tools Was: Re: C-objects and memory use

[Tim Nevels via 4D_Tech]

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
timnev...@mac.com


**
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
**

Re: JSON Tools Was: Re: C-objects and memory use

[David Adams via 4D_Tech]

On Tue, Aug 8, 2017 at 5:14 PM, Keisuke Miyako via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> it seems this view just keeps coming up...
>


> I am sorry if the documentation or marketing material or presentation or
> some other form of communication gave the wrong impression, but Object and
> Array Object are not "4D's way of supporting JSON".
>

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.
**
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
**

Re: JSON Tools Was: Re: C-objects and memory use

[Keisuke Miyako via 4D_Tech]

it seems this view just keeps coming up...

I think it is important to understand that 4D didn't look at JSON and implement 
it as Object and Array Object, doing a really bad job at it, as it were, no, it 
happened the other way round... Object and Array Object were implemented first, 
and then JSON was chosen as a practical way to stringify these new native data 
types. as such, it should not come as a surprise at all that not every JSON can 
be converted to a 4D Object or Object Array. I am sorry if the documentation or 
marketing material or presentation or some other form of communication gave the 
wrong impression, but Object and Array Object are not "4D's way of supporting 
JSON".

> 2017/08/09 5:42、Rick Hazey via 4D_Tech <4d_tech@lists.4d.com> のメール：
>
> [ 1, 2, 3 ]
>
> 4D couldn’t parse it.




**
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
**

Re: JSON Tools Was: Re: C-objects and memory use

[Kirk Brooks via 4D_Tech]

Rick,
You have to use the JSON PARSE ARRAY command.

http://doc.4d.com/4Dv15/4D/15.4/JSON-PARSE-ARRAY.301-3274446.en.html

I wrote a wrapper for JSON strings to look at the first char and then use
the appropriate method.

This is one place where NTK is more convenient since it makes that
adjustment automatically. Which it can do since it simply returns a handle
to the newly created JSON object. 4D can't because it goes ahead and parses
the string into a 4D typed var.

On Tue, Aug 8, 2017 at 1:42 PM, Rick Hazey via 4D_Tech <4d_tech@lists.4d.com
> wrote:

> It’s been a long time since I’ve used 4D and JSON but as I recall one
> problem was the inability to parse JSON where the top level is an array
> instead of an object. IOW, if your JSON looked like this:
> [ 1, 2, 3 ]
>
> 4D couldn’t parse it.
>
-- 
Kirk Brooks
San Francisco, CA
===

*The only thing necessary for the triumph of evil is for good men to do
nothing.*

*- Edmund Burke*
**
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
**

Re: JSON Tools Was: Re: C-objects and memory use

[Rick Hazey via 4D_Tech]

It’s been a long time since I’ve used 4D and JSON but as I recall one problem 
was the inability to parse JSON where the top level is an array instead of an 
object. IOW, if your JSON looked like this:

[ 1, 2, 3 ]

4D couldn’t parse it.

A pretty big deviation from the standard. On the other hand, you can test for a 
top level array, wrap it in an object, and go about your business.

I wrote a JSON parser in 4D code way back in 2011 (and did a Summit session 
about it in 2012) that has no problem handling any valid JSON. Maybe the new 
collection type will allow parsing of top level JSON arrays. Regardless, the 
collection type is a nice addition to the language.


Rick Hazey 
Octet Industries, LLC 
--- 
r...@octethosting.net  
--- 
WWKD?

> On Jul 26, 2017, at 3:13 PM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> ​At the risk of appearing really dense what are the specific things you can
> do with NTK that you can't do with native 4D? I use them both and I just
> don't get what you are referring to. There are differences in the way they
> provide access but I don't see how that results in a limit to what you can
> do.
> 
> And like I said currently you can use native 4D tools to parse a c-obj and
> make a change to a single key of a nested obj and the parent object is
> updated (anyone joining in here should probably read the other thread for
> the details). This is because of the object referencing we talked about in
> the other thread. NTK doesn't support that right now so you can't do it.
> Personally I find that really useful.
> 
> Can you give me an example of the kind of situation you're talking about?​

**
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
**

Re: JSON Tools Was: Re: C-objects and memory use

[David Adams via 4D_Tech]

On Wed, Aug 2, 2017 at 10:51 AM, Jody Bevan via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> David:
>
> Of your four options I choose #1.  ;-)
>

I think that we all do ;-)

Short of 4D improving the language & compiler, I think the least-worst
option is rolling your own code scanner. Such an effort would also be
likely to make it easier to automate test case generation. I spent about 5
months checking these ideas out in a 4D context in the past year, and
that's where I landed.
**
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
**

Re: JSON Tools Was: Re: C-objects and memory use

[Jody Bevan via 4D_Tech]

David:

Of your four options I choose #1.  ;-)





Jody Bevan
ARGUS Productions Inc.
Developer
Argus Productions Inc. 




> On Aug 2, 2017, at 11:34 AM, David Adams via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
> 
> 
> Without compile-time verification of source code errors, you're left with
> these options:
> 
> * Write perfect code every time.
> 
> * Write you own code scanner. Parse your code and process whatever tests
> and checks you can use. This is very fruitful, but a ton of work. It's hard
> to see anyone but a highly motivated individual or a large team doing it.
> 
> * Write very thorough test cases to generate realistic runtime conditions
> to test your code. 4D doesn't have any real test harness available and it's
> not the simplest environment to test anyway. I've seen some good efforts
> and devoted quite a bit of time to this sort of thing myself. Again, price
> of entry is higher than nearly any 4D shop can pay. (Yes, there is a
> UnitTester component from V12 that can be converted...but it only aims to
> solve some problems and you'll still need to retrofit zillions of white box
> tests.)
> 
> * Run you code and deal with the errors when they crop up. At your
> customers.

**
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
**

Re: JSON Tools Was: Re: C-objects and memory use

[David Adams via 4D_Tech]

All of the new features look great and will be most welcome. I'm on R3 now
so R4 should hopefully be an easy transition. For people on 16.1, the new
features won't appear until 17.0.

Dots will definitely make it easier to work with known element names, so
that's great.

I haven't looked at JSON Validate closely yet, but it's leveraging a draft
standard named JSON Schema:

http://json-schema.org/latest/json-schema-validation.html#rfc.section.6

Complicated. Hopefully, it will provide the kind of validation options that
we've been missing. Also hopefully, someone will break it down a bit and
write a tool to compose schemas. Ideally, from a schema you'll be able to
generate new objects generically. Meaning, pass in a schema and get out a
conformant starter object. (Without that, the feature really misses one of
the better pieces of low-hanging fruit.)

Unfortunately, JSON Validate is a *runtime* tool, so it's nothing like a
replacement for a *compiler* improvement. I don't know about you, but I
would greatly prefer to see validation performed on my code "at rest" than
at runtime. Runtime validation has it's place and I'm all for tools that
support it - but that's not ideal for anything but objects that are truly
dynamic and defined at runtime. If they're defined in the code and
accessible to the compiler should check. Sadly, this doesn't seem to be
what 4D's going to do. (Compiler improvements are rare in this respect, the
compiler doesn't test parameter lists thoroughly, doesn't recognize methods
parameters as such, etc.)

Without compile-time verification of source code errors, you're left with
these options:

* Write perfect code every time.

* Write you own code scanner. Parse your code and process whatever tests
and checks you can use. This is very fruitful, but a ton of work. It's hard
to see anyone but a highly motivated individual or a large team doing it.

* Write very thorough test cases to generate realistic runtime conditions
to test your code. 4D doesn't have any real test harness available and it's
not the simplest environment to test anyway. I've seen some good efforts
and devoted quite a bit of time to this sort of thing myself. Again, price
of entry is higher than nearly any 4D shop can pay. (Yes, there is a
UnitTester component from V12 that can be converted...but it only aims to
solve some problems and you'll still need to retrofit zillions of white box
tests.)

* Run you code and deal with the errors when they crop up. At your
customers.
**
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
**

Re: JSON Tools Was: Re: C-objects and memory use

[Tom Swenson via 4D_Tech]

FWIW, it sounds like the object notation in v16r4 is going to alleviate much of 
the pain in dealing with JSON objects..

JSON Validate, Collections and a NULL command!

http://blog.4d.com/en-whats-new-in-4d-v16-r4/




**
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
**

Re: JSON Tools Was: Re: C-objects and memory use

[David Adams via 4D_Tech]

On Wed, Jul 26, 2017 at 12:13 PM, Kirk Brooks via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> David,
> On Wed, Jul 26, 2017 at 10:14 AM, David Adams via 4D_Tech <
> 4d_tech@lists.4d.com> wrote:
>


> Can you give me an example of the kind of situation you're talking about?​
>

Incredibly jet-lagged and short on sleep, so don't expect a great answer. I
dug deep into this a few months back when I was trying to write my own
schema for validation of custom types implemented in objects. I'd done the
same in V13 using NTK's JSON commands. Couldn't get it to work in 4D
because the parsers presume specific formats. Couldn't get the types of
arrays stashed by 4D either. (4D doesn't support collections in any form in
shipping versions open to discussion here.)

As much as I've used JSON in 4D for many years, that's where I come from
with JSON. If you're in JavaScript, it's pretty normal to convert JSON
formats for various reasons. Collections, arrays of objects, objects with
arrays, straight KVPs, flattened arrays...there are a lot of common
formats. I haven't found that flexibility with the built-in commands. When
I asked on the Forums, I came away with the impression that 4D was saying
"Yes, we're incomplete in that sense, but we do this other stuff with it."
Unless I'm mis-remembering, I don't think it was much of a question that
the command set wasn't a full JSON library.

Oh wait, maybe I can offer an explanation you'll agree with. There's a set
of problems where you already know what's in the JSON. Your code "knows"
what's there and, yes, that's what there. That works fine in 4D if you're
doing 4D:4D stuff. No problem. (I'd like to generalize it to emulate
structs, but every way I mention this makes the folks at 4D seem to react
like 1) I'm honking link some kind of deranged goose and 2) A bit of pate
would go nicely right about now.)  Anyway, there's another class of
problems where you either can't know the format in advance (it's coming
from the outside word), or don't want to (because you're writing a
generalized routine to operate on JSON for some reason...I've got lots of
cases like this.) Can you do this kind of blind-but-comprehensive traversal
of a random (but valid) JSON block in 4D? Maybe. I couldn't, despite trying
and following suggestions. Perhaps it's just that it's not set up for that,
or that it's harder than it ought to be. For example, you need to know in
advance what your JSON is at the top: Object or array. Wrong input, you
blow up. I guess you could trap for that, etc. Pain.

If you're doing nothing but 4D:4D work, then there is probably nothing
missing. But that's not the world I live in. It may also be that 4D
improves and can do more. But here's the deal on how I work:

* I've got a requirement. That means that I have the requirement *now*, not
at some unknown future date, so I can only use reliable, shipping tools.
(From whatever source.) I mean, I may have a few weeks or months, but not
long enough to wait for new releases.

* I'll try out what seems to be available in 4D, possibly quite
intensively. Do the features match what I'm trying to do? If not, is there
a workaround? If the answers are "no" and "no", I'm done. I don't follow
up, I don't keep track. It's in the rear view mirror for me. So, upcoming
features are of no use or even much interest to me. I decided about 20
years ago "Only plan around released software that you have in your hands."
That's a rule of thumb I've never regretted. Don't take this to mean me
saying that 4D should do everything that I need, of course that's unlikely.
But if it doesn't, I don't have to wait.

* I do the same with any set of tools, not just 4D, by the way. Actually,
here's my more complete package for tools assessment. Be that an API,
commercial offering, piece of software, etc.

-- Try and solve a real and specific problem. These days, there are so many
options that ticking all of the big boxes may not narrow the field enough.
The details matter. So dig in deeply on a real problem and see how it goes.
This usually takes a couple of days.

-- Need help? Great! Try and get some! Contact tech support, look for
forums, SO threads, etc. It makes a *huge* difference to me how the company
responds. I'm very upfront. If I haven't given them money yet, I just say
"I haven't given you money yet, but I'm checking this out." If I think that
I'm doing something a bit unusual, I tell them so and why. Good customer
service and general communications attitude can make/break a choice.

-- Docs. Super important to me. Maybe more than some...or even more than
most. But without detailed docs, it means that I have to do way more
testing than I want just to figure out how to get things up and running.
That's a big, potentially giant time-sucking hole. *Exactly* the sort of
thing that increases the chances that a tool/product gets cut out of
consideration.
**
4D Internet Users Group (4D iNUG)
FAQ:  

Re: JSON Tools Was: Re: C-objects and memory use

[Kirk Brooks via 4D_Tech]

David,
On Wed, Jul 26, 2017 at 10:14 AM, David Adams via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> Hey, I'm fine that 4D does whatever it wants in C_OBJECTs however they want
> to. Their program, their rules. What I was responding to was Kirk's point
> about JSON per se. If you want to use JSON as an interchange format, we
> don't have a complete set of tools natively in the 4D language. JSON is
> normally treated as a tree (well, it is a tree) that you can parse and
> navigate. In 4D, you can do this using NTK.
>
​At the risk of appearing really dense what are the specific things you can
do with NTK that you can't do with native 4D? I use them both and I just
don't get what you are referring to. There are differences in the way they
provide access but I don't see how that results in a limit to what you can
do.

And like I said currently you can use native 4D tools to parse a c-obj and
make a change to a single key of a nested obj and the parent object is
updated (anyone joining in here should probably read the other thread for
the details). This is because of the object referencing we talked about in
the other thread. NTK doesn't support that right now so you can't do it.
Personally I find that really useful.

Can you give me an example of the kind of situation you're talking about?​

-- 
Kirk Brooks
San Francisco, CA
===

*The only thing necessary for the triumph of evil is for good men to do
nothing.*

*- Edmund Burke*
**
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
**

Re: JSON Tools Was: Re: C-objects and memory use

[David Adams via 4D_Tech]

Hey, I'm fine that 4D does whatever it wants in C_OBJECTs however they want
to. Their program, their rules. What I was responding to was Kirk's point
about JSON per se. If you want to use JSON as an interchange format, we
don't have a complete set of tools natively in the 4D language. JSON is
normally treated as a tree (well, it is a tree) that you can parse and
navigate. In 4D, you can do this using NTK.

I was just saying that here where I live (the 21st century), languages need
the ability to read, write, and navigate arbitrary JSON. The limited
options required/supported by C_OBJECT are fine for 4D's internal purposes,
I guess, but that doesn't address all uses of 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:4d_tech-unsubscr...@lists.4d.com
**

Re: JSON Tools Was: Re: C-objects and memory use

[Peter Bozek via 4D_Tech]

On Wed, Jul 26, 2017 at 12:09 PM, Benedict, Tom via 4D_Tech <
4d_tech@lists.4d.com> wrote:

> David Adams dpad...@gmail.com writes:
>
> >Well, 4D's tools for manipulating JSON are sub-standard, if your goal is
> to parse/produce JSON freely. In this respect, the XML tools (external
> libraries built into 4D) are far more standard and comprehensive.
>
> Along these lines, is there a stable and maintained library for querying
> JSON similar to XPath? I looked for one a few years ago when I was
> developing my Simple Rules Engine but found that there wasn't anything
> mature yet, so I stuck with XML/XPath.
>
> This page http://orangevolt.blogspot.com/2012/12/8-ways-to-query-
> json-structures.html#!/2012/12/8-ways-to-query-json-structures.html
> mentions a number of tools. Anyone have any experience integrating them
> with 4D?
>
>
Note that 4D objects may not be internally not implemented as  JSON data,
but (probably) like hash table - something like std::map. These as standard
does not support even simple constucts like chained keys
(anObject.subObject.subsubObject.property.)


--

Peter Bozek
**
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
**

JSON Tools Was: Re: C-objects and memory use

[Benedict, Tom via 4D_Tech]

David Adams dpad...@gmail.com writes:

>Well, 4D's tools for manipulating JSON are sub-standard, if your goal is to 
>parse/produce JSON freely. In this respect, the XML tools (external libraries 
>built into 4D) are far more standard and comprehensive.

Along these lines, is there a stable and maintained library for querying JSON 
similar to XPath? I looked for one a few years ago when I was developing my 
Simple Rules Engine but found that there wasn't anything mature yet, so I stuck 
with XML/XPath.

This page 
http://orangevolt.blogspot.com/2012/12/8-ways-to-query-json-structures.html#!/2012/12/8-ways-to-query-json-structures.html
 mentions a number of tools. Anyone have any experience integrating them with 
4D?

Tom Benedict
Optum Inc
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
**
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
**