eiffelroom - string - Comments

Done...

paulbates — Wed, 18 Apr 2007 10:42:21 -0700

Wiki document on Immutable Strings.

I think the signature of

mtn — Tue, 17 Apr 2007 09:36:44 -0700

I think the signature of is_equal is subject to change anyway.

like Current will be replaced with ANY IIRC.

-- mTn-_-|

Taking the discussion elsewhere.

paulbates — Tue, 17 Apr 2007 09:33:54 -0700

I'm in the process of creating a Wiki page with rationale and implementation suggestions. I'll post a link when it in at least a legible draft state.

Comparison

colin-adams — Tue, 17 Apr 2007 01:51:22 -0700

I think READABLE_STRING is better than READONLY_STRING_GENERAL (because the dynamic type may also be writable, and I think we will not need _8 and _32 descendants for this class).

For comparison, there is same_string and is_equal. Same_string can accept a READABLE_STRING, and so avoid a conversion, but what about is_equal? It takes a like Current argument, and so a conversion will be involved. Colin Adams

Inherit and convert

ericb — Tue, 17 Apr 2007 00:57:39 -0700

Can't we have both 2) and 3)? Mutable strings would conform to constant strings and constant strings would convert to mutable strings. Comparison would use constant strings as argument and hence conformance would be involved (no performance implications). The problem with STRING_GENERAL inheriting from CONSTANT_STRING_GENERAL is that even though it's a good way for a feature to state that it won't alter strings passed as arguments if declared as constant, it does not mean that this string will not be modified by another feature (or the same feature after assignment attempt) if its dynamic type is in fact one of a mutable string. So we think that the string passed as CONSTANT_GENERAL_STRING will not change, but it can. In fact it's not surprising. Even if the inheritance is appealing, a mutable string is not a constant string. It's like having RECTANGLE inherit from SQUARE. Hmmm, so I guess that in order to be 100% safe we need conversion in both ways. For comparison and performance, we probably need a common ancestor to STRING_GENERAL and CONSTANT_STRING_GENERAL. READONLY_STRING_GENERAL? We can only read the content of the string through this interface, but it's not necessarily a constant string. Polymorphically it can be attached to a mutable string whose content can be modified.

Questionnaire

colin-adams — Mon, 16 Apr 2007 10:14:08 -0700

It might be worth running a poll on this. Options such as:

Keep the status Quo
Have STRING_GENERAL inherit CONSTANT_STRING_GENERAL (breaking all existing Eiffel code)
as my suggestion, despite the performance implications

Colin Adams

I agree

paulbates — Mon, 16 Apr 2007 09:27:30 -0700

Immutable STRING variants are something that I've brought up a number of times. I fully agree that Eiffel needs immutable strings. Keep up the comments.

Performance of string comparisons

colin-adams — Sat, 14 Apr 2007 08:23:13 -0700

The disadvantage of using convert is that the cost of string comparisons, already an expensive operation, is increased by the need to create a temporary object. Colin Adams

CONSTANT_STRING

colin-adams — Fri, 13 Apr 2007 23:49:50 -0700

CONSTANT_STRING_GENERAL, CONSTANT_STRING_8 and CONSTANT_STRING_32 look like better names. Colin Adams

Mutable strings are evil

peter_gummer — Fri, 13 Apr 2007 20:22:35 -0700

I, too, often encounter hard-to-track-down bugs in Eiffel code caused by the fact that STRING is mutable. Every other OO language that I've worked with (Delphi, C#, Java) treats strings as immutable. This is a bit weird, because it means that strings are reference types with some expanded semantics; so the Eiffel approach is more consistent with the rest of the type system. But having a few years of Eiffel development under my belt now, I can safely say that it's not just a prejudice based on what I'm used to: mutable strings are evil!