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

Peter gummer: /* Compatibility */

2007-04-19T03:39:07Z

‎Compatibility

Peter gummer: /* Suggestions to Implementation */

2007-04-19T03:22:14Z

‎Suggestions to Implementation

Peter gummer: /* Immutable Interfaces */

2007-04-19T03:20:38Z

‎Immutable Interfaces

Peter gummer: /* Rationale */

2007-04-19T03:10:53Z

‎Rationale

Peter gummer: /* Rational */

2007-04-18T22:47:41Z

‎Rational

Peter gummer: /* Introduction */

2007-04-18T22:45:15Z

‎Introduction

Paulb: Removed warning and name

2007-04-18T17:41:18Z

Removed warning and name

@@ 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)?

@@ Line 71: / Line 71: @@
 ==Compatibility==
-Before any indicate of how mutable and immutable strings interacte there's needs to be a brief rundown of the possible ways they can interact. There's two schools of thought; Conformance or Conversion.
+Before any indication of how mutable and immutable strings interact, there needs to be a brief rundown of the possible ways they can interact. There are two schools of thought; Conformance or Conversion.
 ===Conformance or Conversion===
@@ Line 80: / Line 80: @@
 ===Examples===
-For the purpose of illustration the following declarations will be used. <code>[eiffel, n]IMMUTABLE_STRING_8</code> is being introduced as a place holder for a immutable variant of the current mutable <code>[eiffel, n]STRING_8</code> class.
+For the purpose of illustration the following declarations will be used. <code>[eiffel, n]IMMUTABLE_STRING_8</code> is being introduced as a place holder for an immutable variant of the current mutable <code>[eiffel, n]STRING_8</code> class.
 <code>[eiffel]
@@ Line 97: / Line 97: @@
 </code>
-In case '''1''' the compiler should recognize the assignment and create a <code>[eiffel]STRING_8</code> using the manifest string. No immutable string should be created. Case '''2''' is effectively the same as case '''1''', just more explicit. Case '''3''' introduces the immutable string. In this case the compiler should reject the call. Immutable strings cannot become mutable. If the conforming option for implement were to be chosen then <code>[eiffel]ms1</code> would be set to <code>[eiffel]Void</code>. An immutable string has been created and it does not conform to <code>[eiffel]STRING_8</code>. Finally case '''4''' leaves room for explanation. In a world of Eiffel immutable strings a once string should behave in the same manner as case '''3'''. Currently it behaves like cases '''1''' and '''2'''.
+In case '''1''' the compiler should recognize the assignment and create a <code>[eiffel]STRING_8</code> using the manifest string. No immutable string should be created. Case '''2''' is effectively the same as case '''1''', just more explicit. Case '''3''' introduces the immutable string. In this case the compiler should reject the call. Immutable strings cannot become mutable. If the conforming option for implementation were to be chosen then <code>[eiffel]ms1</code> would be set to <code>[eiffel]Void</code>. An immutable string has been created and it does not conform to <code>[eiffel]STRING_8</code>. Finally case '''4''' leaves room for explanation. In a world of Eiffel immutable strings a once string should behave in the same manner as case '''3'''. Currently it behaves like cases '''1''' and '''2'''.
 <code>[eiffel]
@@ Line 126: / Line 126: @@
 ====Optimizations====
-The mutable versions of the string class should convert to, and cache, an immutable variant of a string upon an initial request. Once the mutable string's content is modified the cached immutable string is to invalidated. The next request to convert the mutable string to an immutable variant would yield a new immutable string reference.
+The mutable versions of the string class should convert to, and cache, an immutable variant of a string upon an initial request. Once the mutable string's content is modified the cached immutable string is invalidated. The next request to convert the mutable string to an immutable variant would yield a new immutable string reference.
 ====A Common Ancestor====
 Just as <code>[eiffel, n]STRING_GENERAL</code> is available now, a more abstract implementation is required to implement the features available for all string variants. That is; mutable, immutable and 8 and 32 bit versions of each. In the interest of backwards compatibility the use of <code>[eiffel, n]STRING_GENERAL</code> is not a viable solution. A proposed <code>[eiffel, n]ABSTRACT_STRING</code> will instead be put forth for the real general purpose string class.
-<code>[eiffel, n]ABSTRACT_STRING</code> should contain a number of the routines moved up <code>[eiffel, n]STRING_GENERAL</code> and STRING_GENERAL</code> will hence forth derived <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.
+<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==

@@ Line 66: / Line 66: @@
 As it stands today, with only mutable strings, it is not possible to author such classes. A class attribute, or a once function, is open for modification by an unruly client, whether it be accidental through a missing clone of a <code>[eiffel, n]STRING</code>, using twin, or through naivety. Either way, it's dangerous!
-==Suggestions to Implementation==
+==Suggestions for Implementation==
-There are a number of factors to consider before deciding on a implementation choice for immutable string. First and probably most importantly is compatibility. Compatibility raises concerns regarding the assignment of a mutable string to an immutable string, vice-versa and even back again.
+There are a number of factors to consider before deciding on an implementation choice for immutable strings. First and probably most importantly is compatibility. Compatibility raises concerns regarding the assignment of a mutable string to an immutable string, vice-versa and even back again.
 ==Compatibility==

@@ Line 7: / Line 7: @@
 ==Rationale==
-There are a number of reasons why Eiffel needs an immutable representation of a string, which no matter what should be able to be altered. Below explains the rationale for why immutable strings are required in a language, as for those reasons why they are there.
+There are a number of reasons why Eiffel needs an immutable representation of a string, which no matter what should ''not'' be able to be altered. Below explains the rationale for why immutable strings are required in a language, as for those reasons why they are there.
-===EMCA STRING_8 and STRING_32 Are Not Constants===
+===ECMA STRING_8 and STRING_32 Are Not Constants===
-Section 8.29 of the Eiffel ECMA specification details the declaration and use of constants in Eiffel. In section 8.29 the three Eiffel string forms are detailed as being constants. To be pedantic about the matter I extracted a dictional reference for the the word ''constant''.
+Section 8.29 of the Eiffel ECMA specification details the declaration and use of constants in Eiffel. In section 8.29 the three Eiffel string forms are detailed as being constants. To be pedantic about the matter I extracted a dictionary reference for the the word ''constant''.
   ''con·stant'' /ˈkɒnstənt/

@@ Line 6: / Line 6: @@
 The term read-only is not a fitting name so this page documents such string variants as being immutable with its already implemented cousins <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> coined mutable.
-==Rational==
+==Rationale==
-There are a number of reason why Eiffel needs an immutable representation of a string, which no matter what should be able to be altered. Below explains the rationale for why immutable strings are required in a language, as for those reasons why they are there.
+There are a number of reasons why Eiffel needs an immutable representation of a string, which no matter what should be able to be altered. Below explains the rationale for why immutable strings are required in a language, as for those reasons why they are there.
 ===EMCA STRING_8 and STRING_32 Are Not Constants===

@@ Line 2: / Line 2: @@
 ==Introduction==
-On the heals of a point raised on [http://www.eiffelroom.com/blog/colin_adams/read_only_strings eiffelroom] regarding read-only variants of an Eiffel <code>[eiffel, n]STRING</code>, this page has come about to discuss the possible options for introducing such new types.
+On the heels of a point raised on [http://www.eiffelroom.com/blog/colin_adams/read_only_strings eiffelroom] regarding read-only variants of an Eiffel <code>[eiffel, n]STRING</code>, this page has come about to discuss the possible options for introducing such new types.
-The term read-only is not a fitting name so this page documents such string variants as being immutable with it's already implemented cousins <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> coined mutable.
+The term read-only is not a fitting name so this page documents such string variants as being immutable with its already implemented cousins <code>[eiffel, n]STRING_8</code> and <code>[eiffel, n]STRING_32</code> coined mutable.
 ==Rational==

← Older revision		Revision as of 17:41, 18 April 2007
Line 1:		Line 1:
−	~~{{warning\|This article under development and is not ready for any form of review.}}~~
−
−	~~Author: Paul Bates~~
−
	[[Category:EiffelBase]]		[[Category:EiffelBase]]