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

[Martin Friebe]

Michael Van Canneyt wrote:
> On Thu, 11 Sep 2008, Anton Kavalenka wrote:
>   
>> Florian Klaempfl wrote:
>>     
>>> Graeme Geldenhuys schrieb:
>>>       
>>>> Remember, Unicode support is much more that simply storing and
>>>> displaying text. You have various encodings, RTL or LTR direction etc.
>>>> I can't see how a simple type can keep track of all such information
>>>> - but then, I don't know the internals of FPC either.  ;-) 
>>>>         
>>> How would an OOP approach solve this? The problem isn't the tracking of
>>> things like encoding or directions but handling all these information. 
>>>       
>> procedure TLabel.Paint(...)
>> begin
>>  if *Caption.IsRTL *then
>>    DrawCaptionRTL(0,0,*Caption.AsUTF8*, flags)
>> else
>>    DrawCaption(0,0,*Caption.AsUTF8*, flags);
>> end;
>>
>> Is not that enough?
>>     
>
> What is the gain as opposed to
>
>  procedure TLabel.Paint(...)
>  begin
>   if IsRTL(Caption) then
>
> In other words where is the benefit from OOP in this ? 
>
>   
1) keeping track of info:
If you can store the info on an object, so you can store it on a record 
(afaik). And a string (even current string) is nothing else but a 
(hidden) record. It already contains length info, and char data.

2) OO style vs functional:
Caption.IsRtl may be seen as syntactical sugar. But as far as I can see, 
it can (almost?) always be translated into functional style. Instead of 
having child-classes you could overload the function for different types 
of arguments

3) For the real usage of OO using inheritance:
I am not sure if that is a good idea, on any kind of *ref-counted* 
data/object. I can see cases where the full OO power can make sense. But 
using OO the objects should not be ref-counted. (IMHO)
Ref-Counting mainly is used to free memory automatically. People relay 
on it, and you get memory leaks.

Strings as they currently stand can not contain pointer to other 
strings. You can not get circular references. ref-counting will work.
Objects on the other hand can contain any data, including pointers to 
other objects or self. Even if the buildin string-objects don't contain 
that kind of pointer, they can be sub-classed and people will end up 
with circular references.

Oh, and yes, I am aware. This risk already exists with dynarrays. But no 
need to extend it.


So in my opinion, it may be nice to have a library of classes handling 
all kind of string(or shall we call it "text") data. But no magic on 
them. They can use PChar and there own GetMem internally.

Martin