Interface question

[xiaodaigh]

Now that it's getting some serious usage, I've been thinking about the interface.

I think ShortString{UInt32} raises many questions. For a new user, wouldn't they be like? "What's UInt32 got to do with strings"? Is it possible to make it something like ShortString{5} and internally we do something Like

function ShortString{N}(str)
  if 1 < N <= 3
     ShortString{3}(str) # implemented using UInt32
  elseif N < 7
     ShortString{7}(str) # implemented using UInt64
   ....
  end
end

So in this case they might ask why is ShortString{2} the same as ShortString{3}? Then the docs should explain that the only allowed sizes are 3, 7 etc since ShortStrings are backed by primitive types like integers?

I think typing with number of bytes makes more sense to the general audience then using UInt*.

[ScottPJones]

I think that it is useful to use the type, in the actual parameters.
However, the constructor can be changed (as I've already mentioned), to pass the maximum number of bytes.
The output of show can be changed then to match the constructor, ShowString(15), for example.

[ScottPJones]

I also think it would be useful to add a parameter for how the bytes are encoded, so that it's not just limited to storing String, i.e. unvalidated UTF-8 encoded bytes.
For storing text in most of the world, storing UTF-16 would be better which would allow 3 UTF-16 CJK [Chinese-Japanese-Korean], Russian, Indian, Thai, etc. characters would fit in a single UInt64, instead of just 2 characters.