String hierarchy (was: UTC-8 (was ...))

Dean_Swan at Mitel.COM Dean_Swan at Mitel.COM
Mon Mar 20 21:54:03 UTC 2000



From:  Dean Swan at MITEL on 03/20/2000 04:54 PM

Andrew,

     I personally have no strong feelings regarding how the "fat strings" should
be implemented.  I just read that Richard feels that there was a need for
'16-bit byte' arrays, and wanted to point out that if this is indeed required,
then it is already implemented in the distribution image/VM.

     If people aren't overly concerned with space, then it would seem that the
most straightforward implementation would just use an 'Integer' per character.
That would use 4 bytes/character, but then even if you needed an encoding with
more than 2^30 characters, it would "gracefully" overflow into LargeIntegers.
If I were going to undertake this project, this is probably the approach I would
take, then optimize as required, like you suggest.

     I also liked the idea put forth earlier in this thread regarding the
concept of allowing string representation to be encapsulated within the class so
you can subclass to easily do things like 'CompressedString' (some form of
string compression) or 'PackedAsciiString' (i.e. 4 Ascii characters/word), etc.

                                         -Dean Swan
                                         dean_swan at mitel.com







AGREE at CarltonFields.com on 03/20/2000 04:27:51 PM

Please respond to squeak at cs.uiuc.edu

To:   spair at advantive.com, squeak at cs.uiuc.edu
cc:    (bcc: Dean Swan/Ogd/Mitel)

Subject:  RE: String hierarchy (was: UTC-8 (was ...))



Is it apparent that it is necessary?  Perhaps its premature.  Shouldn't we
implement the thing using traditional bit operations or multiplication, and see
how fast it runs before modifying the VM to seek a possibly non-essential
"speedup."  Indeed, perhaps pluggable primitives would suffice if any speedup
were needed.

> -----Original Message-----
> From: MIME :spair at advantive.com > Sent: Monday, March 20, 2000 4:03 PM
> To: squeak at cs.uiuc.edu
> Subject: RE: String hierarchy (was: UTC-8 (was ...))
> > > Maybe what is needed is a "BitArray" where the element size > is
configurable
> (either through subclassing or through an inst var setting).
> > > -----Original Message-----
> > From: Dean_Swan at Mitel.COM [mailto:Dean_Swan at Mitel.COM]
> > Sent: Monday, March 20, 2000 3:03 PM
> > To: squeak at cs.uiuc.edu
> > Subject: RE: String hierarchy (was: UTC-8 (was ...))
> >
> >
> >
> >
> > From:  Dean Swan at MITEL on 03/20/2000 03:02 PM
> >
> > >I wrote:
> > >    > The thing we _do_ need is to have '16-bit byte' arrays
> > >    > supported just like '8-bit byte arrays',
> > >
> > >Someone replied
> > >
> > >    Isn't that a raw implementation detail?
> > >
> > >Yes and no.  If one uses halves of 32-bit bytes or pairs > of 8-bit bytes
> > >then basicSize will be wrong, which would at least be odd.
> >
> >      FWIW, Squeak does have '16-bit byte' arrays.  Look at the
> > 'SoundBuffer'
> > class, which is a subclass of 'ArrayedCollection'.
> >
> >
> >                                    -Dean Swan
> >                                    dean_swan at mitel.com
> >
> >
> >
> > > >










More information about the Squeak-dev mailing list