PR# 19306 Need feedback on ideas for using read-only and immutable strings
Problem Report Summary
Submitter: prestoat2000
Category: EiffelBase
Priority: Medium
Date: 2016/12/08
Class: Support
Severity: Non-critical
Number: 19306
Release: 16.05
Confidential: No
Status: Open
Responsible: jfiat_es
Environment: linux
Synopsis: Need feedback on ideas for using read-only and immutable strings
Description
I know you're very busy with the release, so perhaps you won't answer right away. Almost all of our code was written before read-only strings existed (READABLE_STRING_8), etc. I want to start using read-only strings wherever they make sense. Here are a few ideas on that. Please give me feedback on whether this is the best way to proceed. 1. My first thought is to replace the type STRING with READABLE_STRING_8 in many places. We probably won't ever use STRING_32, except when it comes from Eiffel Software routines. Do you see any disadvantages to doing this, or do you have any alternate suggestions? Or should I use READABLE_STRING_GENERAL instead? 2. The other thing we would like to do is start using immutable strings. Right now, when we retrieve a row from our Oracle database, we are using the type STRING (which is mapped to STRING_8). Clients are not supposed to modify any STRING objects in the returned row, but we currently rely on programmer discipline to achieve that - there is no enforcement. The desire to use immutable strings is what prompted me to submit [EiffelBase #19305] Need new STRING creation procedure since we have a memory address (POINTER) and a length in our hands after we call Oracle to fetch a row. 3. If we start using immutable strings (e.g., IMMUTABLE_STRING_8), we have to be very careful about equality tests. In almost all cases, we just want to check whether two strings are made of the same characters. But since our code is not Void-safe, and probably never will be, we need to handle Void in most places. I thought about writing a routine (in its own class, which would be inherited by classes that need it): frozen same_string (s, t: READABLE_STRING_8) (or READABLE_STRING_GENERAL) do if s = Void or t = Void then Result := t = s else Result := s.same_string (t) end end I would then call this routine in places where I could not guarantee that both strings are non-Void. It also appears that we should not be using the ~ operator, since STRING_8 and IMMUTABLE_STRING_8 have different dynamic types.
To Reproduce
Problem Report Interactions