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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
