> > Whatever you do, please, please, please!!! name the abstract > 
>string class String.  I know that it involves extra steps, > but 
>IMHO would be best to keep the name pure.
> > > Perhaps:
> > > String
> >      UnicodeString
> >          Utc8String
> >              AsciiString
> > > Whatever the intermediate classes you use or don't use, push > 
>the primitive string calls into AsciiString.
>
>I like this a great deal in principle, but am concerned about 
>breaking a great deal of code, that is unless String new: 
>automatically generates an asciiString by default unless the string 
>contains non-ascii codes.  I may be overreacting, and admit I 
>haven't thought at all about it.  In particular,
>
>	String streamContents: [...]

Exactly!  Using the above hierarchy:

ArrayedCollection variableSubclass: #String
	instanceVariableNames: ''
	classVariableNames: 'AsciiOrder CSLineEnders CSNonSeparators 
CSSeparators CaseInsensitiveOrder CaseSensitiveOrder LowercasingTable 
DefaultConcreteType'
	poolDictionaries: ''
	category: 'Collections-Text'

String defaultToAscii!

String class methodFor: 'instance creation'!
new: size
     ^self concreteType basicNew: size
! !

String class methodFor: 'accessing'!
concreteType
     "Note: All concrete subclass of String must reimplement
      this method to answer self !!"

     ^DefaultConcreteType
! !

String class methodFor: 'defaults'!
defaultToAscii
     DefaultConcreteType _ AsciiString.
! !

UnicodeString class methodFor: 'accessing'!
concreteType
    ^self
! !


Also remember that all existing strings in the image would need to 
become instances of AsciiString.


>seems to risk being broken in virtually every changeset in the 
>world, without some special presumption or treatment.  On the other 
>hand, would making such accomodations break the hierarchy?
>
>Finally, is there an ANSI standard issue?


---------------------------------------------------------------------------
   Maurice Rabb    773.281.6003    Stono Technologies, LLC    Chicago, USA