On Oct 23, 2005, at 6:44 PM, Leopold Toetsch wrote:
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'.
I certainly agree that a centralized mechanism for this type of
action is desirable, and it would be silly not to reuse what code we
can. My primary concern here is that we provide an easy way to
register their code. For example, freezing to JSON is the same for
pretty much *every* array PMC type -- in the current implementation,
it's 100% identical. (I think *BooleanArray's should probably be
updated to use true/false for their values)
As long as the PMC class hierarchy permits strategic places to stick
our methods that inherit sanely, I'm all for that. An alternative
would be to upgrade "does" to actually provide methods, and be able
to use these as mixins. (which is actually closer to how JSON/Dumper
are implemented at the moment, they both key off 'does', but outside
the PMC.) This would involve making does a little less fluid than it
is now, but this is a good thing, IMO.
+ # 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?
Already answered, not an issue for JSON. I'd be happy just passing
the recursion error, though with an addition to the freeze interface
to barf on self-referentials instead of handling them, we could
detect this earlier and generate a nicer exception.
Out of curiosity, do you expect to reuse any code for generic
thawing? I would expect that in general you're going to have most of
that in a central location rather than spread out over various vtables.
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
Regards.
