How should other code interact with Corinna instances?

[leonerd]

In particular, it seems inevitable that certain bits of perl/XS/C code are going to want to interact with instances internally, and find out their fields and values of them. I can see three kinds of case here:

1. Modules like Data::Deep, Test::Deep, or the is_deeply() function of Test::More, which will want to recursively inspect the fields of objects in order to compare if they are equivalent
2. Modules like Data::Printer or other debug printers, loggers, etc which will want to peek at the insides of an object in order to print it in some human-readable form, showing the names and current values of all the fields it contains
3. Modules like Storable, YAML, etc... which will want to peek at the insides of an object in order to recursively serialise it in some manner, human-readable or not; and symmetrically will want to be able to recreate new objects with equivalent contents when deserialising them again.

Various other issues (#30, #32) have touched upon facets of this, but not very well. I think it's a specific thing that needs discussing in more detail, with particular reference to all three categories above.

A special mention should be made of modules like Data::Dumper. This module in particular is shipped with core perl, so users have an expectation that it should always work fine with what that version of perl provides. Whatever it does on object instances ought to be "sensible". A definition of "sensible" is hard to come by, because while most people probably think of it as being in category 2 above (a human-readable debug printer), it is not. It is expected that the strings produced by Data::Dumper are valid perl syntax, that can nominally be fed back into eval() to recreate the original values passed in. That therefore makes this module a member of category 3 - and a special one at that in that its serialisation form is not only human-readable but perl-readable; and must be valid perl syntax.

[leonerd]

The API proposed in #63 probably handles most of this quite nicely.

[Ovid]

@leonerd wrote:

1. Modules like Data::Deep, Test::Deep, or the is_deeply() function of Test::More, which will want to recursively inspect the fields of objects in order to compare if they are equivalent
2. Modules like Data::Printer or other debug printers, loggers, etc which will want to peek at the insides of an object in order to print it in some human-readable form, showing the names and current values of all the fields it contains
3. Modules like Storable, YAML, etc... which will want to peek at the insides of an object in order to recursively serialise it in some manner, human-readable or not; and symmetrically will want to be able to recreate new objects with equivalent contents when deserialising them again.

i can see these uses. I would recommend, however, that deconstruct_object make the data read-only or clone the data (or COW) to avoid inevitable bugs if we accidentally change the internal state of an object.

[jjn1056]

This problem would go away if we just used blessed hash-refs for V1 :)