Front page | perl.perl6.internals |
Postings from July 2002
On Tue, Apr 23, 2002 at 04:13:24PM -0400, Dan Sugalski wrote: | Should strings in parrot be mutable or immutable? Right now we've a | mix, and that's untenable. Sorry to comment so late. I think that the choice above isn't good enough. You need both strings and buffers. I say this beacuse there are two fundamental use cases, where you are passing around a string and if you keep a reference to it you don't expect it to change on you. And the other case, is where you are passing around a string (buffer) and it can change on you. Depending on the situation either case can be desireable. My use cases are primarly immutable, while a few people are vocal about mutable strings. Mutable strings aren't necessarly more-useful; in many cases you need to keep a string handle around (say a hashtable key) and know that it won't be changed on you. If you are using mutable strings, this means you have to store a copy of the string in this situation. Storing a string copy has two dis-advantages: first, it means alot of unnecessary duplication, second, it prevents strings to be compared by pointer when they are "interned". Admittedly, you can layer this on top with application semantics; but this is less than ideal as it is a source of bugs. So, I propose that Parrot supports both of these attitudes of reasoning by using a flag. Initially, all strings are 'mutable'. However, they have a 'freeze' operation which turns it into a constant; calling freeze on a constant is a noop. Obviously, there shouldn't be a thaw function and calling a mutator operation on a constant string should raise an error. In this way, application semantics can be enforced uniformly across library and programming language boundaries. If a function asks for a constant string (to keep a copy) then it can call "freeze" on it before it stuffs it away. Then, if some other function tries to change it... the appropriate error condition occurs. This is clean and flexible. That said, one may want to extend this to other types of objects in a more generic manner. Python has both tuples and lists. A tuple is essentially a constant list. Constants are needed for mapping keys, when used as a key, the mapping could 'freeze' the object. Calling 'freeze' on a composite (such as a list or map) would recursively freeze all components of the object and their relation to each other. Something like this would make dictionaries very useable... and would allow for very clean representation of python's list/tuple, buffer/string distinctions. Best, Clark Yo! Check out YAML! http://yaml.org YAML is Serialization for the Masses -- Clark C. Evans Axista, Inc. http://www.axista.com 800.926.5525 XCOLLA Collaborative Project Management SoftwareThread Previous | Thread Next