Immutable Strings - Revision history

Paulb at 19:21, 25 April 2007

2007-04-25T19:21:01Z

Peter gummer: /* Is There a Need for STRING_8 and STRING_32? */

2007-04-19T03:50:44Z

‎Is There a Need for STRING_8 and STRING_32?

Peter gummer: /* Is There a Need to STRING_8 and STRING_32 */

2007-04-19T03:48:22Z

‎Is There a Need to STRING_8 and STRING_32

@@ Line 41: / Line 41: @@
 ===Immutable Interfaces===
-A second rationale is through good design of a class's exported interface. A good design will yield immutable exported members, so as not to seemingly violate such principles of object orientation. I wrote "seemingly" violate, because technically such principles are not violated. The principle in reference is one that states - a class, and its descendants, should be the only entities to modify a respective runtime instantiation's internal state. No client should be permitted to perform such modifications. Technically STRING is a reference type so a qualified call, like append, made on a STRING object, is modifying the internal state of that STRING object. However STRING has special reverence that binds it with the likes of INTEGER, NATURAL and CHARACTER. It's an inbuilt rudimentary type that is seen to be "a value". Almost all other reference types are just objects and runtime with no real discernible value.
+A second rationale is through good design of a class' exported interface. A good design will yield immutable exported members, so as not to seemingly violate such principles of object orientation. I wrote "seemingly" violate, because technically such principles are not violated. The principle in reference is one that states - a class, and its descendants, should be the only entities to modify a respective runtime instantiation's internal state. No client should be permitted to perform such modifications. Technically STRING is a reference type so a qualified call, like append, made on a STRING object, is modifying the internal state of that STRING object. However STRING has special reverence that binds it with the likes of INTEGER, NATURAL and CHARACTER. It's an inbuilt rudimentary type that is seen to be "a value". Almost all other reference types are just objects and runtime with no real discernible value.
 Current EiffelBase abstraction enabled authoring of immutable exported client interfaces, yet allow resident routines to manipulate the internals of an object's state.

@@ Line 138: / Line 138: @@
 So many other languages have chosen to use an immutable string as their fundamental string type. For optimization in creating new strings or piecing parts of strings together a string builder is used. Under .NET there is the immutable <code>[csharp, n]System.String</code> and optimized builder <code>[csharp, n]System.Text.StringBuilder</code>. In Java the exact same story; <code>[java, n]String</code> is an immutable string and <code>[java, n]StringBuffer</code> is used to optimally create immutable strings.
-Yes, choosing such a option would break existing code. But we have to respect that trying to patch rather than change, often causes more problems that breaking code. With code breaking changes there should always be assistants available to help user migrate.
+Yes, choosing such a option would break existing code. But we have to respect that trying to patch rather than change, often causes more problems than breaking code. With code breaking changes there should always be assistants available to help users migrate.
 A simple first step is to change all <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> into <code>[eiffel, n]STRING_BUILDER_8</code> and <code>[eiffel, n]STRING_BUILDER_32</code>, or indeed a unified <code>[eiffel, n]STRING_BUILDER</code> for manipulating any sized string. The breaking changes can be minimized and all future use of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> are known to be immutable. Very little existing code explicit uses <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code>; almost all existing code uses <code>[eiffel, n]STRING</code>; but <code>[eiffel, n]STRING</code> doesn't really exist any more, so mapping it to string builder(s) should be easy.
 Should Eiffel follow suit and deprecate the existing implementation of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code>, in order to favor immutable strings and string builder(s)?

@@ Line 133: / Line 133: @@
 <code>[eiffel, n]ABSTRACT_STRING</code> should contain a number of the routines moved up to <code>[eiffel, n]STRING_GENERAL</code>, and <code>[eiffel, n]STRING_GENERAL</code> will henceforth derive from <code>[eiffel, n]ABSTRACT_STRING</code>. The routines that will not be resident in <code>[eiffel, n]ABSTRACT_STRING</code> will be anything pertaining to mutating the internal representation.
-==Is There a Need to STRING_8 and STRING_32==
+==Is There a Need for STRING_8 and STRING_32?==
-Of course in outlining such a proposal you have to ask the relevance of augments/patching (it depends on your views) Eiffel with immutable strings. Should Eiffel just have immutable strings? It's been discussed that there should be mutable and immutable variants of <code>[eiffel, n]STRING</code>. Deviating from this a moment and looking at the best possible scenario for implementing immutable strings - make mutable strings a thing of the past!
+Of course in outlining such a proposal you have to ask the relevance of augmenting/patching (it depends on your views) Eiffel with immutable strings. Should Eiffel just have immutable strings? It's been discussed that there should be mutable and immutable variants of <code>[eiffel, n]STRING</code>. Deviating from this a moment and looking at the best possible scenario for implementing immutable strings - make mutable strings a thing of the past!
-So many other languages have chosen to use a immutable string as their fundamental string type. For optimization in creating new strings or piecing parts of strings together a string builder is used. Under .NET there is the immutable <code>[csharp, n]System.String</code> and optimized builder <code>[csharp, n]System.Text.StringBuilder</code>. In Java the exact same story; <code>[java, n]String</code> is an immutable string and <code>[java, n]StringBuffer</code> is used to optimally create immutable strings.
+So many other languages have chosen to use an immutable string as their fundamental string type. For optimization in creating new strings or piecing parts of strings together a string builder is used. Under .NET there is the immutable <code>[csharp, n]System.String</code> and optimized builder <code>[csharp, n]System.Text.StringBuilder</code>. In Java the exact same story; <code>[java, n]String</code> is an immutable string and <code>[java, n]StringBuffer</code> is used to optimally create immutable strings.
 Yes, choosing such a option would break existing code. But we have to respect that trying to patch rather than change, often causes more problems that breaking code. With code breaking changes there should always be assistants available to help user migrate.
-As simple first step is to change all <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> into <code>[eiffel, n]STRING_BUILDER_8</code> and <code>[eiffel, n]STRING_BUILDER_32</code>, or indeed a unified <code>[eiffel, n]STRING_BUILDER</code> for manipulating any sized string. The breaking changes can be minimized and all future use of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> are known to be immutable.
+A simple first step is to change all <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> into <code>[eiffel, n]STRING_BUILDER_8</code> and <code>[eiffel, n]STRING_BUILDER_32</code>, or indeed a unified <code>[eiffel, n]STRING_BUILDER</code> for manipulating any sized string. The breaking changes can be minimized and all future use of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> are known to be immutable. Very little existing code explicit uses <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code>; almost all existing code uses <code>[eiffel, n]STRING</code>; but <code>[eiffel, n]STRING</code> doesn't really exist any more, so mapping it to string builder(s) should be easy.
-Should Eiffel follow suit and depreciate the existing implementation of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code>, in order to favor immutable strings and string builder(s)?
+Should Eiffel follow suit and deprecate the existing implementation of <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code>, in order to favor immutable strings and string builder(s)?