Dan Sugalski <[EMAIL PROTECTED]> writes: > At 11:52 AM +0000 1/27/03, Piers Cawley wrote: >>Dan Sugalski <[EMAIL PROTECTED]> writes: >> >>> At 9:24 PM +0000 1/21/03, Piers Cawley wrote: >>>>Dan Sugalski <[EMAIL PROTECTED]> writes: >>>> > Hrm, interesting. Single symbol table for methods and attributes, >>>>> though that's not too surprising all things considered. That may make >>>>> interoperability interesting, but I was already expecting that to some >>>>> extent. >>>> >>>>Isn't that, essentially what Perl 6 will have too? >>> >>> Nope. Attributes and methods will be very separate. Attributes are >>> class-private, more or less, so they won't be in the symbol >>> table. >> >>How private? > > Well... not *that* private. From the bytecode level all this stuff'll > be available, though I hadn't given much thought to the introspection > end of things. > >> We are still going to be able to write some kind of >>serializing tool that won't require tons of per class overloads aren't >>we? (I'd like such a serializing tool to work at the Parrot level with >>possible callbacks into object methods). > > We probably won't need to do that, since all the knowledge necessary > to serialize should be built into individual PMC classes, but yeah, it > should be reasonably doable assuming that particular classes don't > have odd internal structures that aren't otherwise available.
I'm actually quite keen on providing an C<< Object::printOn( $a_stream ) >> type method which can be overridden in weird cases (for instance in Objects that are actually Proxies for something in an external library would need to override the method). I've been working on the 'serialization' problem while writing Pixie so I'm getting some fairy definite ideas about how it should be done :) -- Piers
