On Thu, Sep 02, 2004 at 04:47:40PM -0700, Larry Wall wrote: > > =head1 Compact structs > > A class whose attributes are all low-level types can behave as > a struct.
"all low-level types" or "all low-level *sized* types"? (I'm wondering about char arrays, string and pointers.) I presume a char[n] array within a structure could be represented as an array of int8. That might be uncomfortable to work with. And that a pointer would be... what? Some platforms has odd sizing issues for pointers. Perhaps a "voidp" type is needed? (Which would just be an intN where N is sizeof(void*)*8.) If a "class whose attributes are all low-level types can behave as a struct", is that class then also considered a "low-level type"? (So other structs can be composed from it.) I think that's important because it allows you to avoid having to build too much into the base perl6 language. Semantics like turning an array of int8 with a string with or without paying attention to an embedded null, can be provided by classes that implement specific behaviours for low level types but can still be considered low level types themselves. > (Access from outside the class is still only through > accessors, though.) Whether such a class is actually stored compactly > is up to the implementation, but it ought to behave that way, > at least to the extent that it's trivially easy (from the user's > perspective) to read and write to the equivalent C structure. Is there some syntax to express if the struct is packed or needs alignment? (Perhaps that would be needed per element.) Certainly there's a need to be able match whatever packing and alignment the compiler would use. (I'm not (yet) familiar with Parrot's ManagedStruct and UnManagedStruct types but there's probably valuable experience there.) > That is, when byte-stringified, it should look like the C struct, > even if that's not how it's actually represented inside the class. > (This is to be construed as a substitute for at least some of the > current uses of C<pack>/C<unpack>.) Whether elements are packed or not for byte stringification is, perhaps, orthognal to whether they're packed internally. Network i/o would prefer packed elements and structure interfacing would need aligned elements. Tim.
