On Oct 21, 2005, at 18:07, Will Coleda wrote:
There is now rudimentary support for converting parrot objects to JSON
strings.
+ # generate a JSON representation of a PMC.
+ $S0 = _json( $P0 )
$P0 = new .Array
$P0[0] = $P0
et al, yada yada, ...
Anyway. library/Data/Dumper.imc has the same problem and uses a hash to
track PMC addresses. Parrot's builtin freeze code can of course also
deal with self-referential structures. I'm not sure that a third
(re-)implementation of "all almost the same" code is really a Good
Thing.
There is still another problem with deeply nested structures: recursion
and stack consumption, which is also handled in Parrot core.
Instead of reinventing quadratic wheels I'd rather like to have a
general VTABLE_dump method, which takes an extra structure ('dump_info'
or such) and deals with:
pmc.dump
.repr
.to_json
.perl
.dunno_yet
It's in the same category as the freeze and thaw vtables, the
functionality is like the former one, except a visuable string is
created, details of it depending on further bits found in 'dump_info'.
+ # generate a PMC from a JSON representation:
+ $P1 = _json_to_pmc( "[1,2,3]" )
+ #$P1 is now a array-like container PMC with three Integer elements.
The question is of course, which type of PMC array?
Other concerns: see above - does JSON define to deal with
self-referential structs?
I don't have any objections against JSON - more the opposite of it. I
really like to have a "standard" interface to create e.g. static PMC
constants from strings, and actually such code is already used inside
Parrot to implement the argument passing opcodes.
Just my 2 รง
leo