[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