String hierarchy (was: UTC-8 (was ...))

Bijan Parsia bparsia at email.unc.edu
Tue Mar 21 14:06:29 UTC 2000


--On Sunday, March 19, 2000, 5:38 PM -0600 "Maurice Rabb" <m3rabb at stono.com>
wrote: 

[snip] 
> What does "Stringness" mean?
> What does an object's size-immutability suggest about its
element-mutability?
> 
> Lets go back ...
> 
> A collection is an object which holds group of objects that can be
enumerated.

In what sense? That they're finite? Or that they have a natural
well-ordering (I don't think the latter is true).

> A sequenceable collection is an object which holds a group of objects 
> in an order or sequence. 

I've been wondering why it isn't *sequenced* collection :)

> The protocol of SequenceableCollection 
> strongly assumes that that its members are mutable by both element 
> and size.

Really? I'd have thought that SequencableCollection, being abstract, is
merely *silently* on whether it is mutable by element or by size.
ArrayedCollection is a subclass, eh?

Not fixing  and strongly assuming aren't the same.

> An arrayed collection is the same as a sequenceable except that is 
> refined as being of fixed size.  (More precisely of fixed capacity.) 
> There is no refinement regarding element-mutablity, so the natural 
> assumption is that arrayed collections are also mutable.  Aside from 
> its sequential nature, being of fixed size _defines_ what it means to 
> be an ArrayedCollection.

But surely not an *Array*. I.e., being of fixed size is not what, in its
purest form, characterizes an Array. (I suspect it's more about the Big 0
for various operations, that and having empty positions. I.e., an array is a
sequence of *positions*, not of elements, or, perhaps, only derivatively of
elements.)

> Now we come to strings.  What are the critical characteristics that 
> define something as being a String?  A string is a sequence of 
> characters.  In its purest form that's its definition.  The 
> definition explicitly assumes nothing about its element or size 
> mutability.  Therefore, it seem most appropriate that it is a type of 
> SequenceableCollection instead of a type of ArrayedCollection.

Well, maybe the abstract class, sure. But, for example, printed strings are
fixed in both element and size (barring extraordinary erasure efforts).

Common Lisp, I understand, *defines* a string as an array of characters
(where arrays are mutable in both ways, I believe). I think a lot of this
has to do with how the elements are *addressable*. This suggests that the
"problem" lies in ArrayedCollecition's name :) After all, I suspect that
OrderedCollection is merely a slightly optimized VariablySizedArray (I
haven't checked, though).

> I think that one can make a compelling argument that strings should 
> be completely immutable.  Under any circumstance, I think that we 
> will all agree that at a minimum, there should be the option of have 
> immutable strings.  Some would argue that we have this with symbols. 
> We do, but the defining characteristic of symbols is uniqueness.

So:
        String
                ImmutableString
                        Symbol

Sounds good to me.

> My long winded point is that mutability (and uniqueness) are 
> orthogonal to the basic notions of type.  Mutablility and uniqueness 
> of aspects that appropriate for all types of objects.  We could 
> implement these notions by subclass immutable versions of classes, 
> however given their global nature these characteristics are best 
> implement by other means.

That seems right. Or rather, do it by subclassing, and have an abstract
superclass generate the appropriate concrete class on demand (rather like
FileStream). This would even allow switch between, say, mutable and
immutable strings if the compiler can prove that no mutable calls will be
had (or one could mutate on demand, or do copy on demand, etc.)

> Since we don't have aspects yet, IMHO the most elegant means is by
delegation.

Hmm. Please compare to the above strategy, since if that's true (and I've
sketch something different than what you meant) we may want to do it for
FileStream as well.

> So back to strings, if we implement them by delegating to a contents 
> collection, we can let the contents determine the mutability rules of 
> the string.  Going back to the original point of this family of 
> threads, we can let the contents determine the encoding of the string.

Hmm. Letting  the character of its contents, rather than the characters that
are it's contents, determine the coding? That's sounds fine.

(This comment was made solely to enable the pun.)

> I hope that you will excuse the abstractness of my discussion. 

Well, maybe. This time. Don't let it happen again! :)

> However as I have stated in previous postings, I believe good naming 
> is _very_ important.

Yes, but now I wonder why you thing Arrays (much less ArrayedCollections)
are "by nature" fixed in size.

> One of the things that surprises me most when talking about 
> programming with people who are not engineers or lawyers,

You mean like with us philosophers?

> is how hard 
> it is for it to sink in exactly with however must precision software 
> must be write for it to work (at all).

Er...I really must be too fuzzy headed, pie-in-the-sky, armchair
philosophery for you :)

>  A program can't just express 
> the gist of what you want.  It needs to exactly express what you want 
> it to do.  Definition is everything in our business.

Urk. ("No Bijan, don't go there! Stay away!" :))
[snip]
>>But this isn't an *accident* of implementation, imho, it's a design
>>decision (to have immutable strings).
> 
> I agree that it is a design decision.  I just question whether or not 
> it is a good design decision.  I just think that if you are going to 
> make strings immutable, don't make them partially immutable.  Make 
> them either completely immutable, or completely mutable.

Well, that sums it up!

I don't know though. If collectoins are collections of pointers (in some
sense) then, absent single assignment, rebinding should be permitted, eh?
Or, at least, I don't see why not.

[snip]
> True.  Except (at the risk of repeating myself from above) forget 
> about MutableString.  Just have plain ol' String as a subclass of 
> OrderedCollection.  Lets its delegate determine its mutability.

You mean it's delegate, MutableString? ;)

I think there's an issue about what we want to expose to the programmer. Do
we want programmers to have to decide whether to use a mutable or
non-mutable string? Is it just a background optimization?

(BTW, if you have immutability, why care one way or another about
uniqueness?)
 
[streaming idea] 
> That is an interesting notion.  Personally, I find it awkward to 
> allow element mutability but not size immutability.  If I am going to 
> be allow to modify a collection, hey! let me modify it!   I am 
> willing to work will the size-immutablity of array types, because, 
> hey! that's what it means to be an array!

Again, I don't see that. I thought arrays had more to do with
insertion/deletion/accessing characterisitcs (as opposed to, e.g., linked
lists). Of course Smalltalk Arrays *are* of fixed size, but that's a
different point, eh?

[snip]
> Don't let the tone of my posts in this thread mislead you from my 
> preference for immutability as the default for strings.  Surprised? 

Nope.

Cheers,
Bijan Parsia.





More information about the Squeak-dev mailing list