At 9:54 AM -0400 7/11/02, Clark C . Evans wrote:
>On Wed, Jul 10, 2002 at 11:21:10AM -0400, Dan Sugalski wrote:
>| I'm not sure that the place to enforce read-onlyness is at the
>| string/buffer level. Doing it at the PMC level is more likely the
>| right place to do it.
>
>Therefore, "read-onlyness" would be a property of any ole
>object and not just strings?
Yes.
>If so, I think this is a
>great direction; as long as it is a mechanism shared by
>each language binding. For YAML serializations, it would
>insist that each mapping key is "read-only". Perfect.
Yes. There's a standard set of properties and, while individual
languages can call them whatever the heck they want, const-ness is
const-ness regardless.
>This brings up another topic. Will parrot have reflection
>or must this be done at the application level?
It will have reflection, introspection, and Deep Meditative Capabilities.
>It would be
>very nice to have reflection down in the parrot guts so that
>we can write serialization tools that operate while being
>oblivious to the current language (or perhaps this is a bit
>too much... just musing here).
Serialization will require a bit more work than plain introspection
can guarantee, since there's nothing stopping someone from writing a
PMC class that stores random arbitrary data in a buffer and uses it
in ways that Parrot has no real clue about.
There were serialization/deserialization in the PMC vtables at one
point, but that's gone. I think I may add it back in, though of
course no PMC is required to provide them.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
