String hierarchy (was: UTC-8 (was ...))
Maurice Rabb
m3rabb at stono.com
Fri Mar 17 09:26:33 UTC 2000
> > 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
More information about the Squeak-dev
mailing list
|