On Sat, Aug 13, 2005 at 19:08:09 +0200, Ingo Blechschmidt wrote:

>  BTW, is it even necessary to support user-defined serializing
>  behaviours? (After all, an Item can only be an Int, Num, Str, Ref, Bit,
>  Pair, Junc, Type, Code, Undef, and Object in PIL2 [1].)


Yes, because data types may implicitly depend on the state of the
real world, like an object that contains an Int, which is some
process' PID.

We should have a Serializable role, and a 'serializable' property:

class Moose is Serializable { # everything is implicitly
# serializable, but this is "formal"
	has $foo is serializable(....); # how is this serializable
	has $bar; # automatically serialized
}

In any sense, class Moose promises that it can be safely serialized,
regardless.

Implicitly serializable objects are determined per instance -
whether or not their instance data is completely serializable, and
there is also a complement role:


class Elk is UnSerializable { # or something more catchy

}

explicitly stating that this cannot be fixed.

I would expect DBI::Handle to be unserializable, but in theory you
could recompose the Serializable role on top of it on a per
application basis, and tie this into an application config
mechanism, so that if the configuration handle can be serialized,
the database handle can be thawed using it.


When serializing an unserializable object the compiler whines or
dies depending on options ('use fatal' in the class's definition
scope?). Implcitily unserializable objects will be serialized, but
their unsafe context might not.

Anything that is explicitly unserializable is thawed into a class
whose AUTOMETHOD is just a thin wrapper for 'fail'.

With this structure strictly unserializable objects can be minimized
- for example a file handle object can retain the path it was opened
with, it's mode, it's position in a seekable file, it's modes, and
the only thing which is truely unserializable is the file descriptor
itself. The object could be semi-useful under unsafe serialization
if the user wants that.

-- 
 ()  Yuval Kogman <nothingmuch@[...].org>  0xEBD27418  perl hacker &
 /\  kung foo master: /me spreads pj3Ar using 0wnage: neeyah!!!!!!!!!!!