>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Well, if we provide a primitive for this (a big if) I expect it
DS> can be piggy-backed onto the GC code somehow, which needs to do
DS> the same sorts of things.
the tree/structure scanner could be shared. in fact since GC has to
detect loops with the mark pass, you get a clean copy as well.
DS> No doubt. This is where the interesting work resides, which is why
DS> I'm all up for passing the buck to the mythical CLONE sub. :0
what about this approach: we provide a UNIVERSAL::CLONE (damian's idea
as usual!) which does a clean deep copy if possible. when it detects
wacko things like tied objects, it tries to skip them cleanly or invoke
some method to clone it. any class can provide a CLONE method to allow
local overloading of the CLONE method.
if that class method invocation occurs within a single perl op (assuming
deep copy is written internally and not in perl), it is like a thread
and that brings up issues. it is more like reentering the interpreter or
even recursing. is this something to think about when creating the
internals. i said in the async I/O RFC that the entire interpreter
should be fully reentrant to support threads cleanly.
it all ties together. that is the perlish way.
better GC begets better cloning which is supported by needing threads.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
