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