The type is called ansistring simply for backwards compatibility.
You could start arguing that everything should be intuitive. Take C
for example. What does the && operator tell you about what it does?
Shouldn't it have a intuitive form? But in the end this is how the
language is and this is a use
avoids automatic
conversion between types as much as possible.
I feel that it's a goody of a strongly typed language that automatic
type conversions can be done by creating the appropriate code statically
instead of having this embedded in the objects as with variants.
If doing a simple a
Michael Schnell schrieb:
> Felipe Monteiro de Carvalho wrote:
>> Ignore the name "ansi". Take it as a string type with the system
>> encoding. I think it will solve the confusion.
>>
> Of course if you ignore "ANSI" and just use the type named "String"
> there is no confusion as it's clear that
IMHO it has been already discussed too often.
I did not start it and only 1% of the contributions are mine - and yours
-, so quite obviously there is a decent common wish for a solution of
what is percept as a problem.
-Michael
___
fpc-devel ma
Felipe Monteiro de Carvalho wrote:
Ignore the name "ansi". Take it as a string type with the system
encoding. I think it will solve the confusion.
Of course if you ignore "ANSI" and just use the type named "String"
there is no confusion as it's clear that the coding is not predefined.
That
Zitat von Michael Schnell <[EMAIL PROTECTED]>:
>
> > For me, these attempts to make compiler do everything automatically sound
> > like getting yet another typing saver.
> Maybe I am just being lazy, but it's not a typing saver but regarding
> the previous not-Unicode aware versions it's more a "p
On Tue, Dec 2, 2008 at 9:00 AM, Michael Schnell <[EMAIL PROTECTED]> wrote:
> I still don't understand what ANSI has to do with "System".
Ignore the name "ansi". Take it as a string type with the system
encoding. I think it will solve the confusion.
--
Felipe Monteiro de Carvalho
I now understand that GB2312 and JIS 0213 in fact are the ANSI code
pages 936 and 932.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
UTF-8 is unicode and it is the system encoding on linux, OS X, some BSDs and
Solaris. So ansistrings are UTF-8 there.
I still don't understand what ANSI has to do with "System".
AFAIK, The term "ANSI Code" stands for a (codepage depending) definition
for a character encoding and Unicode is
Op Tue, 2 Dec 2008, schreef Michael Schnell:
Thanks for pointing this out.
GB2312 suits them well. Likewise, JIS 0213 suits the Japanese well.
Are these called "ANSI" ?
Yes, code page 936 and code page 932 are valid ANSI code pages.
These standards by themselves of course not, because t
For me, these attempts to make compiler do everything automatically sound
like getting yet another typing saver.
Maybe I am just being lazy, but it's not a typing saver but regarding
the previous not-Unicode aware versions it's more a "preventer of a
typing enhancer" :) .
OTOH it's not just
Mattias Gärtner schrieb:
> Zitat von Florian Klaempfl <[EMAIL PROTECTED]>:
>
>> Mattias Gaertner schrieb:
>>> You can optimize for one encoding or optimize for one per platform. I
>>> know how to optimize for widestrings, for ansistring and for UTF-8
>>> strings, but I have no experience in optimi
Michael Schnell schrieb:
> Thanks for pointing this out.
>>
>> GB2312 suits them well. Likewise, JIS 0213 suits the Japanese well.
> Are these called "ANSI" ?
Every well educated windows programmer knows that the ansi
functions/strings whatever are not limited to the so-called "ansi" code
pages (
Zitat von Michael Schnell <[EMAIL PROTECTED]>:
>
> > The point is: if everybody takes care of the fact that ansistrings can
> > be multibyte, having utf-8 in ansistrings (if it's the locale encoding),
> > is no big deal at all.
> >
> I do understand. But (in a real world) do you know anybody who d
Thanks for pointing this out.
GB2312 suits them well. Likewise, JIS 0213 suits the Japanese well.
Are these called "ANSI" ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
It simply needs no explicit support except what it has already. Mainly
the rtl and the user program has to take care of it and we did this
already in the rtl but the compiler required no fix in this regard so far.
I do see your point !
But my point is that with the introduction of Unicode,
Zitat von Florian Klaempfl <[EMAIL PROTECTED]>:
> Mattias Gaertner schrieb:
> > You can optimize for one encoding or optimize for one per platform. I
> > know how to optimize for widestrings, for ansistring and for UTF-8
> > strings, but I have no experience in optimizing for multiple
> > encoding
Michael Schnell wrote:
The more I think about it the more I like this solution. I think it's
better then the previous idea of a string with encode information
inside it.
Would Lazarus be able to follow ?
Do you think it's possible to have the compiler take care of any
necessary conversion
Michael Schnell schrieb:
>
>>> If just ignoring the fact is enough support, OK, it's supported :).
>>>
>>
>> What FUD is this? Pleaes give an example where the FPC compiler doesn't
>> handle multi byte ansistrings properly.
>>
> Sorry for bad language :( ! I did not mean to be aggressive.
Op Tue, 2 Dec 2008, schreef Michael Schnell:
I supposed one of the main intentions for the move to Unicode was the ability
to support Chinese above all. So they did not seem to have been content with
what was done before.
Is anybody from China here to offer the footage ?
It is not the Chi
If just ignoring the fact is enough support, OK, it's supported :).
What FUD is this? Pleaes give an example where the FPC compiler doesn't
handle multi byte ansistrings properly.
Sorry for bad language :( ! I did not mean to be aggressive. (Did you
see the smile indicator ?)
I di
Michael Schnell schrieb:
>
>> So, really? What is not supported?
>>
> If just ignoring the fact is enough support, OK, it's supported :).
What FUD is this? Pleaes give an example where the FPC compiler doesn't
handle multi byte ansistrings properly.
Or do you just want to troll around? This p
So, really? What is not supported?
If just ignoring the fact is enough support, OK, it's supported :).
... tell this 1+ Billion (Billion=10^9 in this case) people in China.
I did not know (or suppose) that code used for Chinese characters is
called "ANSI" ("American National Standards I
Op Tue, 2 Dec 2008, schreef Michael Schnell:
Nobody talks in this case about UTF-8. Even *ANSIstrings* in there
native meaning can contain multi byte chars, there are *multi byte* ansi
char sets.
If there is a widely used multi-byte ANSI encoding, why so we need Unicode ?
IMHO the introduc
Michael Schnell schrieb:
>
>> The point is: if everybody takes care of the fact that ansistrings can
>> be multibyte, having utf-8 in ansistrings (if it's the locale encoding),
>> is no big deal at all.
>>
> I do understand. But (in a real world) do you know anybody who does.
>
> If it would b
The point is: if everybody takes care of the fact that ansistrings can
be multibyte, having utf-8 in ansistrings (if it's the locale encoding),
is no big deal at all.
I do understand. But (in a real world) do you know anybody who does.
If it would be "appropriate" for ANSI code handling to
Michael Schnell schrieb:
>
>> Nobody talks in this case about UTF-8. Even *ANSIstrings* in there
>> native meaning can contain multi byte chars, there are *multi byte* ansi
>> char sets.
> If there is a widely used multi-byte ANSI encoding, why so we need
> Unicode ?
>
> IMHO the introduction of
Nobody talks in this case about UTF-8. Even *ANSIstrings* in there
native meaning can contain multi byte chars, there are *multi byte* ansi
char sets.
If there is a widely used multi-byte ANSI encoding, why so we need
Unicode ?
IMHO the introduction of Unicode has been necessary as (like you
Michael Schnell schrieb:
>
>>> Ignoring that ANSI Characters > $7F are locale depending makes a program
>>> work perfectly in a single country and mostly decently in many others.
>>>
>>
>> So it works in far east with its multi byte ansi encodings?
>>
> These of course are not part of the
Ignoring that ANSI Characters > $7F are locale depending makes a program
work perfectly in a single country and mostly decently in many others.
So it works in far east with its multi byte ansi encodings?
These of course are not part of the "many others". (BTW handling Russian
with ANS
The more I think about it the more I like this solution. I think it's
better then the previous idea of a string with encode information
inside it.
Would Lazarus be able to follow ?
Do you think it's possible to have the compiler take care of any
necessary conversions automatically ?
-Mic
It is not helpful because on an utf-8 system ansistring contains utf-8.
Ansistring just means: use the system locale 8 bit encoding.
I meant it would be helpful to (optionally) have a complete ANSI based
system (as was the previous version of Lazarus and FPC).
I don't understand what you m
Michael Schnell schrieb:
>
>> Don't forget that the ansistring type is actually multiple encodings and
>> even multi byte (even not considering UTF-8). The point is: nobody took
>> care of it.
>>
> IMHO a major confusion is generated by calling a string that is supposed
> to hold UTF8 data "ANS
Don't forget that the ansistring type is actually multiple encodings and
even multi byte (even not considering UTF-8). The point is: nobody took
care of it.
IMHO a major confusion is generated by calling a string that is supposed
to hold UTF8 data "ANSIString". This never should have happene
Felipe Monteiro de Carvalho schrieb:
> On Mon, Dec 1, 2008 at 8:27 PM, Mattias Gaertner
> <[EMAIL PROTECTED]> wrote:
>> I don't see, how a TLCLStrings will *not* break Delphi and Lazarus
>> compatibility. Maybe you can give some more details, how it should work.
>
> It was just a initial idea. I n
Michael Schnell schrieb:
>
>> I meant more that a lot of people simply ignored in their code that
>> ansistrings could be also multibyte even not considering UTF-8.
>>
> Ignoring that ANSI Characters > $7F are locale depending makes a program
> work perfectly in a single country and mostly dece
Mattias Gaertner schrieb:
> You can optimize for one encoding or optimize for one per platform. I
> know how to optimize for widestrings, for ansistring and for UTF-8
> strings, but I have no experience in optimizing for multiple
> encodings.
Don't forget that the ansistring type is actually mult
I meant more that a lot of people simply ignored in their code that
ansistrings could be also multibyte even not considering UTF-8.
Ignoring that ANSI Characters > $7F are locale depending makes a program
work perfectly in a single country and mostly decently in many others.
Ignoring that
Not to mention: What would the alternative be?
Even if I am not satisfied with the current state of Lazarus on that
behalf, I would not dare to suggest that Lazarus should do any change
here before the next version of FPC offers a new string handling with
either a string type that knows it
Btw will the LCL remain forcedly UTF-8 ? I thought the current Lazarus
unicode support was temporary and all options were still open, depending on
the outcome of FPC unicode support options?
I understand they could not do it differently (other than just providing
no Unicode support at all), may
This is about the same as having all string routines in 3 flavours:
RTLString, utf-8 and utf-16
What about (real) ANSIString (OS/locale based coded) ? This needs to be
allowed as the program might need to read such files.
-Michael
___
fpc-devel m
I never suggested the RTL to be in a fixed encoding. I fully agree
that this would be far worse.
I suppose there are (quite decently workable) solutions for this. Either
the RTL (and LCL, FWIW) comes in multiple versions that are used as
appropriate (user selectable and/or automatically select
In our previous episode, Micha Nelissen said:
> > There are an immense amount of similar examples possible (and if you add
> > operator overloading in the mix, it increases exponentially), and you'd
> > get a huge amount of "can't decide which overloaded function to call"
> > errors even if the
In our previous episode, Felipe Monteiro de Carvalho said:
> On Mon, Dec 1, 2008 at 7:33 PM, Martin Friebe <[EMAIL PROTECTED]> wrote:
> > I suggested to have a rtl, that has overloaded functions for each string
> > type.
> > of course that sounds easier than in fact it will be.
>
> This is about t
Op Mon, 1 Dec 2008, schreef Felipe Monteiro de Carvalho:
The real world problem is (as Florian wrote): Some platforms have no
choice, because they only support 'ansi'.
This one is trivial to solve. Lazarus supports utf-8 everywhere,
including Windows 98 which doesn't support unicode. All you
> The real world problem is (as Florian wrote): Some platforms have no
> choice, because they only support 'ansi'.
This one is trivial to solve. Lazarus supports utf-8 everywhere,
including Windows 98 which doesn't support unicode. All you need is a
best effort approach.
--
Felipe Monteiro de Ca
Luiz Americo Pereira Camara escreveu:
Initially i'm not in favor of using RTLString,, IMO LCL should choose
an encoding UTF16 or UTF8 and then let the compiler convert only the
system calls.
The complete phrase: "Initially i'm not in favor of using RTLString, IMO
LCL should choose an encod
On Mon, 1 Dec 2008 21:23:34 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> In our previous episode, Mattias Gaertner said:
> > > In our previous episode, Mattias Gaertner said:
> > > > >
> > > > > I see this as a theoretic consideration. Please give a real
> > > > > world (!) code ex
Felipe Monteiro de Carvalho escreveu:
I think it's the other way around. If you know what encoding is
expected you have a more predictable result. You know where a
conversion will take place. For example:
MyUTF8String := MyRTLString;
So we get an error that characters are being lost, but only i
Mattias Gaertner wrote:
[...]
Also it would be nice (so I do not know how) not to have to
duplicate code, in order to archive this. Something like generics,
maybe.
The goal of RTLString is to avoid duplicate code in the RTL.
Yes I acknowledged that this would be a probl
On Mon, Dec 1, 2008 at 8:34 PM, Luiz Americo Pereira Camara
> I asked this once and no one did an affirmative. I hope this gets clear
> soon, to avoid problems with code of third part LCL developers (like me).
I'll start a discussion about this in lazarus-dev.
--
Felipe Monteiro de Carvalho
On Mon, 01 Dec 2008 21:50:11 +
Martin Friebe <[EMAIL PROTECTED]> wrote:
> Mattias Gaertner wrote:
>[...]
> Yes I agree, and said so before: If a rtl function is going to pass
> on the data to the OS, and conversation is always needed, then no
> overloading is needed. Use RTLString.
>
> If an
Marco van de Voort escreveu:
In our previous episode, Felipe Monteiro de Carvalho said:
This is the part I like about this approach. The most likely fixed
encoding to be adopted would be UTF-16, and something not very nice
would happen to Lazarus users in UNIXes:
LCL (UTF-8) --> RTL (UTF
On Mon, Dec 1, 2008 at 8:27 PM, Mattias Gaertner
<[EMAIL PROTECTED]> wrote:
> I don't see, how a TLCLStrings will *not* break Delphi and Lazarus
> compatibility. Maybe you can give some more details, how it should work.
It was just a initial idea. I now see that TStrings could be improved.
--
Fe
Graeme Geldenhuys escreveu:
On Mon, Dec 1, 2008 at 10:03 PM, Mattias Gaertner
<[EMAIL PROTECTED]> wrote:
and it avoids unneeded conversions.
I understand it 'avoids unneeded conversions' *inside* the RTL, by
adding implicit conversions to the code accessing the RTL.
This is exa
Point taken.
And point also taken that it's not a solution to to a "half job",
meaning overload only methods based on parameters, but not results. This
would be a false pretence, ending people n a believe they do the right
thing where they do not.
Another idea:
The programmer should be able
On Mon, 1 Dec 2008 18:35:26 -0200
"Felipe Monteiro de Carvalho" <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 1, 2008 at 6:22 PM, Mattias Gaertner
> <[EMAIL PROTECTED]> wrote:
> > Compatibility was always the bigger goal for lazarus. IMHO a
> > TLCLStrings breaks more than it would solve.
>
> You mean
On Mon, Dec 1, 2008 at 8:21 PM, Martin Friebe <[EMAIL PROTECTED]> wrote:
> If you have a function overloaded in utf6 and utf16, then You will not need
> to have it in RTLString. RTLString will be equal to either of the 2?
But it's easier to implement like I proposed, and it seams some people
want
Felipe Monteiro de Carvalho wrote:
On Mon, Dec 1, 2008 at 7:33 PM, Martin Friebe <[EMAIL PROTECTED]> wrote:
I suggested to have a rtl, that has overloaded functions for each string
type.
of course that sounds easier than in fact it will be.
This is about the same as having all string r
On Mon, Dec 1, 2008 at 7:26 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>> A string whose encoding is unknown is very inconvenient for
>> developers.
>
> I don't see that so strongly as most.
I know I spoke only generally, but it's hard to speak about and
foresee the effects of something whi
Marco van de Voort escreveu:
In our previous episode, Luiz Americo Pereira Camara said:
string[index], copy, pos, length have always been part of Pascal.
So keep using ansistring? It doesn't change.
Not true if fpc will follow Delphi. The new AnsiString type will be also
Marco van de Voort wrote:
In our previous episode, Mattias Gaertner said:
Florian Klaempfl wrote:
[...]
My opinion is that it should be the programmers choice. I a
programmer wants or needs a simpler way (keeping all the strings in
is application in one format, which will be known to him) the
Felipe Monteiro de Carvalho wrote:
On Mon, Dec 1, 2008 at 10:13 AM, Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
I assume that the new variable encoding type would be used for all
unicode routines, am I right?
No, it will be RTLString which type depends on the OS.
The more I thi
Jonas Maebe wrote:
There are an immense amount of similar examples possible (and if you add
operator overloading in the mix, it increases exponentially), and you'd
get a huge amount of "can't decide which overloaded function to call"
errors even if the compiler were hacked to take the use of th
Mattias Gaertner wrote:
On Mon, 01 Dec 2008 15:06:45 +
Martin Friebe <[EMAIL PROTECTED]> wrote
That would mean that in order to avoid conversation, some functions
of the RTL would be needed in overloaded versions for each string
type. IMHO this applies only to those, which do not (or not alw
On 01 Dec 2008, at 22:33, Martin Friebe wrote:
I suggested to have a rtl, that has overloaded functions for each
string type.
of course that sounds easier than in fact it will be.
Florian pointed out a few issues, like overloading by result is not
possible (yet?).
No, it is fundamentally
Felipe Monteiro de Carvalho schrieb:
> On Mon, Dec 1, 2008 at 7:24 PM, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>> So how did people work for years with ansistring?
>
> A ansistring used in the way proposed by FPC is extremely inconvenient
> for any GUI application which will be run in differen
On Mon, Dec 1, 2008 at 7:33 PM, Martin Friebe <[EMAIL PROTECTED]> wrote:
> I suggested to have a rtl, that has overloaded functions for each string
> type.
> of course that sounds easier than in fact it will be.
This is about the same as having all string routines in 3 flavours:
RTLString, utf-8 a
Luiz Americo Pereira Camara wrote:
Martin Friebe escreveu:
All the code
Widestring := RtlFunction;
Utf8string := RtlFunction;
will run, it may just perform badly.
Yes and no.
Let's assume the platforms windows and unix having UnicodeString
(UTF-16) and UTF8String as native types respective
On Mon, Dec 1, 2008 at 7:24 PM, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> So how did people work for years with ansistring?
A ansistring used in the way proposed by FPC is extremely inconvenient
for any GUI application which will be run in different parts of the
globe. You develop a applicatio
In our previous episode, Florian Klaempfl said:
> > A string whose encoding is unknown is very inconvenient for
> > developers. The idea just saves itself in the RTL because of the
> > eventual need to do some extremely high performance applications. For
> > Lazarus it would be simply a useless inc
In our previous episode, Felipe Monteiro de Carvalho said:
> > RTLString, IOW encoding platform dependant. Except maybe selected widgets
> > like
> > synedit. (Borland stores source in utf-8 too on windows)
>
> A string whose encoding is unknown is very inconvenient for
> developers.
I don't se
Felipe Monteiro de Carvalho schrieb:
> On Mon, Dec 1, 2008 at 7:01 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>> RTLString, IOW encoding platform dependant. Except maybe selected widgets
>> like
>> synedit. (Borland stores source in utf-8 too on windows)
>
> A string whose encoding is unkn
On Mon, Dec 1, 2008 at 7:01 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> RTLString, IOW encoding platform dependant. Except maybe selected widgets like
> synedit. (Borland stores source in utf-8 too on windows)
A string whose encoding is unknown is very inconvenient for
developers. The idea
On Mon, Dec 1, 2008 at 7:03 PM, Luca Olivetti <[EMAIL PROTECTED]> wrote:
>> LCL (UTF-8) --> RTL (UTF-16) ---> Operating System (UTF-8)
>
> Is the last step always true? Doesn't qt support utf-16?
This is for operating system calls, not graphical library calls.
--
Felipe Monteiro de Carvalho
En/na Felipe Monteiro de Carvalho ha escrit:
LCL (UTF-8) --> RTL (UTF-16) ---> Operating System (UTF-8)
Is the last step always true? Doesn't qt support utf-16?
Bye
--
Luca
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.f
In our previous episode, Felipe Monteiro de Carvalho said:
> On Mon, Dec 1, 2008 at 6:48 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> > Btw will the LCL remain forcedly UTF-8 ? I thought the current Lazarus
> > unicode support was temporary and all options were still open, depending on
> > t
On Mon, 1 Dec 2008 18:45:46 -0200
"Felipe Monteiro de Carvalho" <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 1, 2008 at 6:38 PM, Marco van de Voort <[EMAIL PROTECTED]>
> wrote:
> > In our previous episode, Graeme Geldenhuys said:
> > IOW, you give the programmer the choice about the type, instead of
>
On Mon, Dec 1, 2008 at 6:48 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> Btw will the LCL remain forcedly UTF-8 ? I thought the current Lazarus
> unicode support was temporary and all options were still open, depending on
> the outcome of FPC unicode support options?
It is certainly not tem
In our previous episode, Felipe Monteiro de Carvalho said:
> This is the part I like about this approach. The most likely fixed
> encoding to be adopted would be UTF-16, and something not very nice
> would happen to Lazarus users in UNIXes:
>
> LCL (UTF-8) --> RTL (UTF-16) ---> Operating Syste
On Mon, 1 Dec 2008 21:07:50 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> In our previous episode, Felipe Monteiro de Carvalho said:
> > > You did nail a big problem though, and a weakness in Delphi's
> > > design. What to do with classes that are used both straight and
> > > in the
In our previous episode, Jonas Maebe said:
> > Do they have some way to indicate that a procedure/method only supports
> > a certain encoding?
>
> No.
>
> > Or do you have to manually force the encoding in that way?
>
> Yes.
Clear. I just wondered how they solved it.
> > I prefer a declarativ
On Mon, Dec 1, 2008 at 6:38 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> In our previous episode, Graeme Geldenhuys said:
> IOW, you give the programmer the choice about the type, instead of forcing
> him an arbitrary one, based on your favorite platform.
This is the part I like about this
In our previous episode, Graeme Geldenhuys said:
> >> and it avoids unneeded conversions.
> >
> > I understand it 'avoids unneeded conversions' *inside* the RTL, by
> > adding implicit conversions to the code accessing the RTL.
>
> This is exactly what I was thinking. The conversion is simply pass
On Mon, Dec 1, 2008 at 6:22 PM, Mattias Gaertner
<[EMAIL PROTECTED]> wrote:
> Compatibility was always the bigger goal for lazarus. IMHO a TLCLStrings
> breaks more than it would solve.
You mean compatibility with Delphi?
With Tiburon I think this will become very hard, if possible at all.
We can
On Mon, Dec 1, 2008 at 10:03 PM, Mattias Gaertner
<[EMAIL PROTECTED]> wrote:
>
>> and it avoids unneeded conversions.
>
> I understand it 'avoids unneeded conversions' *inside* the RTL, by
> adding implicit conversions to the code accessing the RTL.
This is exactly what I was thinking. The convers
In our previous episode, Mattias Gaertner said:
> > encoding.
> >
> > That would actually require less fixups (a few conversions procedures
> > for the rare points where tlclstrings are passed to e.g. registry
> > units. Lazarus already has their own XML units).
>
> Only at places where we had t
On Mon, Dec 1, 2008 at 6:22 PM, Mattias Gaertner
<[EMAIL PROTECTED]> wrote:
> Compatibility was always the bigger goal for lazarus. IMHO a TLCLStrings
> breaks more than it would solve.
I don't fully understand how the Tiburon TStrings works, but consider
that we are used to mixing TStrings with L
On 01 Dec 2008, at 21:17, Marco van de Voort wrote:
In our previous episode, Jonas Maebe said:
(nsstring)
The advantage when using such a type is that you also only need to
convert it (internally, hidden from the user) on demand or when some
helper routine requires it (such as e.g. case-inse
In our previous episode, Mattias Gaertner said:
> > In our previous episode, Mattias Gaertner said:
> > > >
> > > > I see this as a theoretic consideration. Please give a real world
> > > > (!) code example when this causes a problem.
> > >
> > > Can you give a real world example where a differen
In our previous episode, Mattias Gaertner said:
>
> > and it avoids unneeded conversions.
>
> I understand it 'avoids unneeded conversions' *inside* the RTL, by
> adding implicit conversions to the code accessing the RTL.
It allows the user to stay conversion free, and have some control over ho
In our previous episode, Jonas Maebe said:
(nsstring)
> The advantage when using such a type is that you also only need to
> convert it (internally, hidden from the user) on demand or when some
> helper routine requires it (such as e.g. case-insensitive
> comparisons). Otherwise, no convers
In our previous episode, Felipe Monteiro de Carvalho said:
> On Mon, Dec 1, 2008 at 5:40 PM, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> >> What string type will be TStrings.Items and the many other strings in
> >> the classes.pp?
> >
> > Not yet decided though I'd make them RTLString as well.
>
On Mon, 1 Dec 2008 17:53:58 -0200
"Felipe Monteiro de Carvalho" <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 1, 2008 at 5:50 PM, Marco van de Voort <[EMAIL PROTECTED]>
> wrote:
> > You did nail a big problem though, and a weakness in Delphi's
> > design. What to do with classes that are used both stra
On 01 Dec 2008, at 20:57, Felipe Monteiro de Carvalho wrote:
On Mon, Dec 1, 2008 at 5:40 PM, Florian Klaempfl <[EMAIL PROTECTED]
> wrote:
What string type will be TStrings.Items and the many other strings
in
the classes.pp?
Not yet decided though I'd make them RTLString as well.
I think
In our previous episode, Felipe Monteiro de Carvalho said:
> > You did nail a big problem though, and a weakness in Delphi's design.
> > What to do with classes that are used both straight and in the GUI?
>
> You mean like TStrings?
>
> I think we will eventually roll our own TUTF8Strings
>
> We
On Mon, 1 Dec 2008 20:44:32 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> In our previous episode, Mattias Gaertner said:
> > >
> > > I see this as a theoretic consideration. Please give a real world
> > > (!) code example when this causes a problem.
> >
> > Can you give a real wor
On Mon, 01 Dec 2008 20:40:14 +0100
Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> Mattias Gaertner schrieb:
> > On Mon, 01 Dec 2008 16:36:23 +0100
> > Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> >
> >> [...] Martin Friebe schrieb:
> >>> I can not see how I can interpret RtlString[1]. If the resu
On Mon, Dec 1, 2008 at 5:40 PM, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>> What string type will be TStrings.Items and the many other strings in
>> the classes.pp?
>
> Not yet decided though I'd make them RTLString as well.
I think you can't change TStrings because that would break all code
us
On Mon, Dec 1, 2008 at 5:50 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
> You did nail a big problem though, and a weakness in Delphi's design.
> What to do with classes that are used both straight and in the GUI?
You mean like TStrings?
I think we will eventually roll our own TUTF8Strings
1 - 100 of 131 matches
Mail list logo
