[fpc-devel] Unicodestring branch, please test and help fixing

Michael Van Canneyt michael at freepascal.org
Wed Sep 10 16:00:33 CEST 2008



On Wed, 10 Sep 2008, listmember wrote:

> Michael Van Canneyt wrote:
> > You are mixing 2 things. There is the actual string content, and there is
> > the
> > string metadata. The metadata is something that would apply for flyweight
> > pattern. There is nothing to be gained by putting the metadata in an object,
> 
> This is true --upto a point.
> 
> And, that point arises when you wish to be able to work further with a
> TCharacter.
> 
> Say, you're doing text processing --display and all. You would definitely like
> to be able to derive a new class from TCharacter and call it, say,
> TWPCharacter which contains all sorts of other properties, color, style, font,
> size etc.
> 
> This would make life immensely easier for such jobs whereby a character may
> need to have more attributes than there exists in the base class.
> 
> > since there is only the encoding. Storing the encoding in an object is
> > ridiculous and a waste of heap space. a 2 byte encoding is less wasteful
> > than a 4 or 8 byte object pointer.
> 
> I am afraid I do not agree with this at all. Or rather, it comes accross a
> very ANSI-centric view.

You are mixing 2 things:

- Texts (strings) at the compiler language level.
- (complex) GUI design that needs to handle a lot of text and a lot of extra
  properties.

For GUI design, you may well need all the things you describe. 
And as I said before: you can do this yourself if you need it.

But at the _language level_, there is no need for all these things. 
They make simple usage of the language impossible. To burden the 
pascal language with all these things would be a serious mistake.

But there is nothing that stops people from doing all these things 
for themselves if they require it.

Michael.



More information about the fpc-devel mailing list