On Sat, 08 Mar 2003 06:58, Dan Sugalski wrote: > At 2:08 PM +1300 3/7/03, Sam Vilain wrote: > >As long as mechanisms are put in place to allow modules to bypass > > object encapsulation and private/public constraints, and given that > > Parrot will have no XS, > > It wouldn't be wise to jump from "Parrot won't do perl 5's XS scheme" > to "Parrot won't have a way to write code for it in C". It will, > arguably, be *easier* in parrot to write parts of your program in C, > thus making it more likely that less of an object will be guaranteed > to be done entirely in parrot-space.
OK. Perhaps those structures should have a method/PMC that they must export which will dump their internal state into a near equivalent Parrot data structure rather than just having serialisation methods, for the sake of the tools that want to traverse it rather than just freeze/thaw it to a stream. ie, something that extracts their state and can be passed to `bless' et al to reconstruct the original object. The structure freezer & heater can ask objects to present themselves as core types for serialisation. I think this would be a great debugging win as well. -- Sam Vilain, [EMAIL PROTECTED] Real computer scientists like C's structured constructs, but they are suspicious of it because its compiled. (Only Batch freaks and efficiency weirdos bother with compilers, they're soooo un-dynamic.)
