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.
Presenting internal state in a rational form is a rather significantly different thing than being able to serialize things, and I don't think it's feasable, unfortunately. It'll require too much consistency to be useful (as I don't think you'll get that consistency) and you'll likely end up just dropping back and grovelling over the internal nasty bits anyway.
Serialization is a specific and very useful application, and one that we need in general (otherwise we won't be able to have constant PMCs) so it'll be there, but being able to expect to walk a pool of heterogenous objects from a variety of different object systems is more than I think you're likely to get.
More to the point, it's a level of complexity I'm unwilling to commit to, because it's not needed for our required functionality, useful though it might be. (Even in the limited circumstances it's likely to be available in)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
