Re: [lazarus] The use of Variants?
Graeme Geldenhuys wrote: Hi, What are your feelings about the use of Variants? I'm debating this in another NG and would like some outside opinion. My personal opinion on Variants: * I don't like them. [if that's a reason] :-) Well they were darn useful in Delphi when dealing with com objects and embedding wsh scripting stuff. * They seem like a bit of a hack. Native types seem to be a better solution to me, even though it might end up being a bit more work (coding wise). better solution just exposes your area of main experience rather than making any definitive comment on the use of variants. Spme people think object pascal and C are a hack and we should have just stuck with machine code whatever makes the job easier without offending reason (I'm thinking of BF here) * They tend to be slow compared no native types. In Delphi 6 they were very slow. How does it compare in FPC 2.2.0? Well, however slow they may be it's better than doing it by hand; if people use variants where they don't need to they have their-selves to blame for any slowness. So. I've found 'em useful... Sam _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] The use of Variants?
Graeme Geldenhuys schrieb: Hi, What are your feelings about the use of Variants? I'm debating this in another NG and would like some outside opinion. My personal opinion on Variants: Variant based code is a nightmare to maintain. Just let somebody else extend some variant based code. How should he know what a variant could contain at a certain place? Such extensions are simply very error prone to rte because of type mistaches. Variants are a step back to assembler level: there you work also basically with typeless memory locations and other people have to guess what a memory location could contain. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] The use of Variants?
Michael Van Canneyt wrote: On Tue, 13 Nov 2007, Graeme Geldenhuys wrote: * They tend to be slow compared no native types. In Delphi 6 they were very slow. How does it compare in FPC 2.2.0? They are slower than native types, there is no way around this. Almost each and every operation involving variants has some implicit calls to variant support routines. If the variant type is the correct type, no casts are done and the whole thing is very quick. You should see that it is more than double the size. If that doesn't convince someone that variants are SLOW, then I don't know what will. Use -al for compiler options. Twice as big doesn't mean slow at all. Most of the extra code covers different branches based on the variant type, most of the extra code is NEVER used but there in case because, as you say, pascal is a type safe language. I would much rather have pascal manage the variant and conversions for me than I have to manage it and get it wrong. Sam _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] The use of Variants?
Florian Klaempfl wrote: Graeme Geldenhuys schrieb: Hi, What are your feelings about the use of Variants? I'm debating this in another NG and would like some outside opinion. My personal opinion on Variants: Variant based code is a nightmare to maintain. Just let somebody else extend some variant based code. How should he know what a variant could contain at a certain place? Why stop at variants? Undocumented code IS a nightmare. Such extensions are simply very error prone to rte because of type mistaches. nonsense. You easily get to check types, even before any automatic casting. Variants are a a union struct (C talk here) with automatic helper routines IF needed. Variants are a step back to assembler level: there you work also basically with typeless memory locations and other people have to guess what a memory location could contain. They aren't typeless at all, part of the structure indicates the type! Pascal can check the type AND cast the type IF you want it to and it is needed. They are only slow if the type needs casting, in which case you were going to have ot cast it anyway. Sam _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] The use of Variants?
On Tue, 13 Nov 2007, Sam Liddicott wrote: Michael Van Canneyt wrote: On Tue, 13 Nov 2007, Graeme Geldenhuys wrote: * They tend to be slow compared no native types. In Delphi 6 they were very slow. How does it compare in FPC 2.2.0? They are slower than native types, there is no way around this. Almost each and every operation involving variants has some implicit calls to variant support routines. If the variant type is the correct type, no casts are done and the whole thing is very quick. Exactly: IF. this means a) Check if. This by itself involves a call to a helper routine. b) convert if not the same With native types it's just a straight copy. You should see that it is more than double the size. If that doesn't convince someone that variants are SLOW, then I don't know what will. Use -al for compiler options. Twice as big doesn't mean slow at all. Just have a look at the code before saying that :-) Most of the extra code covers different branches based on the variant type, most of the extra code is NEVER used but there in case because, as you say, pascal is a type safe language. It must be checked, each time over and over again. Just look at the code. I would much rather have pascal manage the variant and conversions for me than I have to manage it and get it wrong. The point is that you don't need to do conversions when using typed variables. Michael. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] The use of Variants?
* Michael Van Canneyt wrote, On 13/11/07 08:47: On Tue, 13 Nov 2007, Sam Liddicott wrote: Michael Van Canneyt wrote: On Tue, 13 Nov 2007, Graeme Geldenhuys wrote: * They tend to be slow compared no native types. In Delphi 6 they were very slow. How does it compare in FPC 2.2.0? They are slower than native types, there is no way around this. Almost each and every operation involving variants has some implicit calls to variant support routines. If the variant type is the correct type, no casts are done and the whole thing is very quick. Exactly: IF. this means a) Check if. This by itself involves a call to a helper routine. It can be a simple compare. The delphi variant code that I disassembled was inline (hence twice as big, doesn't involve a call but a simple compare). The simple compare to determine the variant type is nothing compared to the overheads that will exist between the two systems communicating using the variants. b) convert if not the same With native types it's just a straight copy. With variants it is usually a straight copy, and in cases where it usually isn't you were going to have to convert by hand anyway. You should see that it is more than double the size. If that doesn't convince someone that variants are SLOW, then I don't know what will. Use -al for compiler options. Twice as big doesn't mean slow at all. Just have a look at the code before saying that :-) I have disassembled the delphi variant code, ls -l doesn't give an indication of execution time. Most of the extra code covers different branches based on the variant type, most of the extra code is NEVER used but there in case because, as you say, pascal is a type safe language. It must be checked, each time over and over again. Just look at the code. The check is cheap. The conversion doesn't need to happen over and over again unless you want it to. People who really want to can use the variant to aid a one-off conversion to a native statically typed variable, and this is STILL neater and simpler and less error prone than managing a manual type check and conversion and dealing with any error. I would much rather have pascal manage the variant and conversions for me than I have to manage it and get it wrong. The point is that you don't need to do conversions when using typed variables. This is not true; take most situations where variants are being used and you see they are being used to manage conversions. Type-ing of variables does not avoid the need for conversion. (Variants are typed in both senses, but I know what you mean). Variants may or may not be a hack, but they are less of a hack than the alternative. If people use variants when not integrating with duck-typing systems then they get the performance penalty they deserve. In this conversation I'm thinking of using variants when integrating with COM systems, etc; Perhaps you are thinking of lazy users who make everything a variant so they can have some kind of loosely typed compiled pascal-script. The fault would be with the user, not the variant. Sam
Re: [lazarus] The use of Variants?
On Nov 13, 2007, at 10:12 AM, Sam Liddicott wrote: * Michael Van Canneyt wrote, On 13/11/07 08:47: On Tue, 13 Nov 2007, Sam Liddicott wrote: Michael Van Canneyt wrote: On Tue, 13 Nov 2007, Graeme Geldenhuys wrote: * They tend to be slow compared no native types. In Delphi 6 they were very slow. How does it compare in FPC 2.2.0? They are slower than native types, there is no way around this. Almost each and every operation involving variants has some implicit calls to variant support routines. If the variant type is the correct type, no casts are done and the whole thing is very quick. Exactly: IF. this means a) Check if. This by itself involves a call to a helper routine. It can be a simple compare. The delphi variant code that I disassembled was inline (hence twice as big, doesn't involve a call but a simple compare). The simple compare to determine the variant type is nothing compared to the overheads that will exist between the two systems communicating using the variants. b) convert if not the same With native types it's just a straight copy. With variants it is usually a straight copy, and in cases where it usually isn't you were going to have to convert by hand anyway. You should see that it is more than double the size. If that doesn't convince someone that variants are SLOW, then I don't know what will. Use -al for compiler options. Twice as big doesn't mean slow at all. Just have a look at the code before saying that :-) I have disassembled the delphi variant code, ls -l doesn't give an indication of execution time. Most of the extra code covers different branches based on the variant type, most of the extra code is NEVER used but there in case because, as you say, pascal is a type safe language. It must be checked, each time over and over again. Just look at the code. The check is cheap. The conversion doesn't need to happen over and over again unless you want it to. People who really want to can use the variant to aid a one-off conversion to a native statically typed variable, and this is STILL neater and simpler and less error prone than managing a manual type check and conversion and dealing with any error. I would much rather have pascal manage the variant and conversions for me than I have to manage it and get it wrong. The point is that you don't need to do conversions when using typed variables. This is not true; take most situations where variants are being used and you see they are being used to manage conversions. Type-ing of variables does not avoid the need for conversion. (Variants are typed in both senses, but I know what you mean). Variants may or may not be a hack, but they are less of a hack than the alternative. If people use variants when not integrating with duck-typing systems then they get the performance penalty they deserve. In this conversation I'm thinking of using variants when integrating with COM systems, etc; Perhaps you are thinking of lazy users who make everything a variant so they can have some kind of loosely typed compiled pascal-script. The fault would be with the user, not the variant. I think it is the same debate between C++ programmers et PHP programmers. The first group like strong type checking because they want to know exacty how their data must be. The second one don't care of it and want lazy programming. I do not agree with that, variant are not needed the most of the time, you always have a pascal routine to make your convertion if needed. If you always need a convertion, may be the type/modeling is not appropriated. Even if we have powerful computer nowdays, it is not necessary to add useless checks/code. We seek for performance because you don't want to be forced to have a 3GHz to open an explorer... Another reason would be that I observe with a lazy programming language that programmers don't take care of their code and provide unmaintable code. But it is only my thought -- Damien Gerard [EMAIL PROTECTED]
Re: [lazarus] The use of Variants?
* Damien Gerard wrote, On 13/11/07 09:31: I think it is the same debate between C++ programmers et PHP programmers. Nearly. It's a meta-debate on whether or not pascal users should be ALLOWED to use variants, not whether or not pascal should implement everything as a variant. The first group like strong type checking because they want to know exacty how their data must be. Or maybe the tedium of conformity is appealing? There are so many of them it is difficult to know all their reasons. I've had to write too much API-glue and conversion in my time, perhaps thats why I like variants. I re-wrote swig-php to make it easier and of course ended up writing even more in the process :-) The second one don't care of it and want lazy programming. This may often be true, but it is also as often un-true. I find it interesting that you choose a flattering generalization for those you agree with and an un-flattering generalization for those you disagree with; and yet it is not clear that those php programmers you disagree with care for pascal and variants anyway. I find generally that when there are two sides to a debate, both sides fail to properly grasp the facts of the other view, preferring to cling to the straw which better justifies their own opinion. If you find duck-typing programmers lazy and not worth associating with, you will never learn that you are wrong. I started hard-core programming in SH, then Turbo Pascal, then Delphi; I wrote a 16 bit multi-threader (later absorbed without permission into a Delphi 2 compat library for Delphi 1, I wrote a Delphi 1 form designer well before lazarus, and also an implementation of form inhertiance for Delphi 1). I wrote DPMI extensions to handle call-backs from real-mode device drivers in Delphi. I then went on to PHP and C and re-wrote php-swig to easily link libraries with php (doing all these variant type conversions). I then went on to MS embedded visual C++ for smartphones. Now lazarus is GTK2 and doesn't make my eyes bleed on linux, I'm getting ready to do wince development with lazarus so I can keep my code when I finally get a linux smartphone. I've spent years on both sides of the typing fence, and say confidently that anyone who sits strongly on one side of the fence is speaking from a lack of experience. I do not agree with that, variant are not needed the most of the time, yes. And fortunately pascal won't raise any warnings if you don't use them. you always have a pascal routine to make your convertion if needed. but you have to write the code every time. You have to write code to check, convert and raise an exception and there aren't even any decent C style macros to help you do it!! It is NUTS. On top of that the compiler COULD easily do it for you. If you always need a convertion, may be the type/modeling is not appropriated. Maybe it is appropriate and maybe you are writing an interface between systems. I accept that you haven't found the need for variants, but please consider there might be a need. Even if we have powerful computer nowdays, except we are not allowed to have this powerful computer automatically generate the code for us, we have to write it ourselves. it is not necessary to add useless checks/code. But it is necessary to add USEFUL checks/code, and if the compiler can do it for me, so much the better. We seek for performance because you don't want to be forced to have a 3GHz to open an explorer... The FACILITY of variants has nothing to do with performance. The ABUSE of variants has everything to do with performance. But why stop at variants? The abuse of alternate record parts (union in C, I forgot what pascal calls them) is also hell. The abuse of embedded read-write procedures on file records is nuts. Another reason would be that I observe with a lazy programming language that programmers don't take care of their code and provide unmaintable code. Are you opposed to the facility of variants because you think a load of lazy slack programmers will suddenly start using lazarus like they did VB? But it is only my thought I agree with your statements, but I can't see how they are relevant to the facility of variants. Why do those who oppose the facility of variants base their arguments on the situation where only idiots would be using them? I hope the answer is not because it helps them believe they are right. - of course such statements will useless to persuade those who do see other value in variants precisely because it is OTHER value that they see I keep stating why COM is useful; it automatically checks, converts and raises exceptions with data from other systems. It saves a lot of possibly buggy code from having to be written, debugged and maintained by hand. Why aren't people complaining about the overhead of widget encapsulation? Why only about type encapsulation? Because the people who complain about widget encapsulation are not using lazarus so we can't hear them. Sam
Re: [lazarus] The use of Variants?
On Nov 13, 2007, at 10:59 AM, Sam Liddicott wrote: * Damien Gerard wrote, On 13/11/07 09:31: I think it is the same debate between C++ programmers et PHP programmers. Nearly. It's a meta-debate on whether or not pascal users should be ALLOWED to use variants, not whether or not pascal should implement everything as a variant. The first group like strong type checking because they want to know exacty how their data must be. Or maybe the tedium of conformity is appealing? There are so many of them it is difficult to know all their reasons. I've had to write too much API-glue and conversion in my time, perhaps thats why I like variants. I re-wrote swig-php to make it easier and of course ended up writing even more in the process :-) The second one don't care of it and want lazy programming. This may often be true, but it is also as often un-true. I find it interesting that you choose a flattering generalization for those you agree with and an un-flattering generalization for those you disagree with; and yet it is not clear that those php programmers you disagree with care for pascal and variants anyway. I find generally that when there are two sides to a debate, both sides fail to properly grasp the facts of the other view, preferring to cling to the straw which better justifies their own opinion. If you find duck-typing programmers lazy and not worth associating with, you will never learn that you are wrong. I started hard-core programming in SH, then Turbo Pascal, then Delphi; I wrote a 16 bit multi-threader (later absorbed without permission into a Delphi 2 compat library for Delphi 1, I wrote a Delphi 1 form designer well before lazarus, and also an implementation of form inhertiance for Delphi 1). I wrote DPMI extensions to handle call-backs from real-mode device drivers in Delphi. I then went on to PHP and C and re-wrote php-swig to easily link libraries with php (doing all these variant type conversions). I then went on to MS embedded visual C++ for smartphones. Now lazarus is GTK2 and doesn't make my eyes bleed on linux, I'm getting ready to do wince development with lazarus so I can keep my code when I finally get a linux smartphone. I've spent years on both sides of the typing fence, and say confidently that anyone who sits strongly on one side of the fence is speaking from a lack of experience. I do not agree with that, variant are not needed the most of the time, yes. And fortunately pascal won't raise any warnings if you don't use them. you always have a pascal routine to make your convertion if needed. but you have to write the code every time. You have to write code to check, convert and raise an exception and there aren't even any decent C style macros to help you do it!! It is NUTS. On top of that the compiler COULD easily do it for you. If you always need a convertion, may be the type/modeling is not appropriated. Maybe it is appropriate and maybe you are writing an interface between systems. I accept that you haven't found the need for variants, but please consider there might be a need. Even if we have powerful computer nowdays, except we are not allowed to have this powerful computer automatically generate the code for us, we have to write it ourselves. it is not necessary to add useless checks/code. But it is necessary to add USEFUL checks/code, and if the compiler can do it for me, so much the better. We seek for performance because you don't want to be forced to have a 3GHz to open an explorer... The FACILITY of variants has nothing to do with performance. The ABUSE of variants has everything to do with performance. But why stop at variants? The abuse of alternate record parts (union in C, I forgot what pascal calls them) is also hell. The abuse of embedded read-write procedures on file records is nuts. Another reason would be that I observe with a lazy programming language that programmers don't take care of their code and provide unmaintable code. Are you opposed to the facility of variants because you think a load of lazy slack programmers will suddenly start using lazarus like they did VB? VB I don't know I have stopped using Windows as my primary dev platform for many years :) But it is only my thought I agree with your statements, but I can't see how they are relevant to the facility of variants. Why do those who oppose the facility of variants base their arguments on the situation where only idiots would be using them? I hope the answer is not because it helps them believe they are right. - of course such statements will useless to persuade those who do see other value in variants precisely because it is OTHER value that they see I keep stating why COM is useful; it automatically checks, converts and raises exceptions with data from other systems. It saves a lot of possibly buggy code from having
Re: [lazarus] The use of Variants?
* Damien Gerard wrote, On 13/11/07 10:43:
I don't think nobody is complaining here since everybody is free to
use it or not.
Oh some people complain about the widget encapsulation ??? So they
don't use QT as well and if they want a multiplatform software what do
they use ? Java ? :)
And as it was said before, why using variants when standard types are
enough ? Just to see in your code S := N instead of S := IntToStr(N); ?
For your example, you are converting the way that does not require
variants, so of course it shows that variants are not required. Please
excuse this example being in mostly-C;
int s;
if (data.t == D_INT) {
s=data.t_int.value;
} else if (data.t == D_LONGINT) {
if (data.t_longint.value MAXINT) error();
s=data.t_longint.value);
} else if (data.t == D_STR) {
errno=0;
s=strtol(data.t_str.value, NULL. 10);
if (errno!=0) error();
} else {
error();
}
(I already spotted some mistakes, imagine maintaining all that rubbish)
At least in C you can come up with a load of helper macros.
And did you try and use COM in the delphi 1 days? It was utterly mad.
People made it work and THEN gave up.
Variants let the programmer concentrate on the meaning of the code when
integrating with other systems. Often the overhead of what was being
controlled was nothing to the overhead of the variant (and of course,
this was being managed by hand in Delphi 1 anyway). And the overhead of
writing code with variants was much less than writing code that did it
all by hand.
People keep re-inventing COM and variants all over the shop because they
don't have com and variants when the need them.
Variants are good things but they were not created to allow lazy
programming or implicit convertions. They were made in order to
provide a dynamic type when you can't know the type of the variable
(in SQL queries for example).
Maybe that's why there were made, but they were put into Delphi to
allow implicit conversions from unspecified types from systems that use
unspecified types, and to let Delphi use easily integrate with systems
that use unspecified types.
There's nothing wrong with an implicit conversion if the generated code
is pretty much exactly what you would (should) have explicitly written.
anyway... I think we fully explored other peoples opinions. I think you
don't like variants because they ways in which I (also) think other
people shouldn't use them are bad.
Sam
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] The use of Variants?
On Nov 13, 2007, at 12:03 PM, Sam Liddicott wrote:
* Damien Gerard wrote, On 13/11/07 10:43:
I don't think nobody is complaining here since everybody is free to
use it or not.
Oh some people complain about the widget encapsulation ??? So they
don't use QT as well and if they want a multiplatform software what
do
they use ? Java ? :)
And as it was said before, why using variants when standard types are
enough ? Just to see in your code S := N instead of S :=
IntToStr(N); ?
For your example, you are converting the way that does not require
variants, so of course it shows that variants are not required. Please
excuse this example being in mostly-C;
int s;
if (data.t == D_INT) {
s=data.t_int.value;
} else if (data.t == D_LONGINT) {
if (data.t_longint.value MAXINT) error();
s=data.t_longint.value);
} else if (data.t == D_STR) {
errno=0;
s=strtol(data.t_str.value, NULL. 10);
if (errno!=0) error();
} else {
error();
}
Remind me to kill every one in my team who write this kind of code...
(I already spotted some mistakes, imagine maintaining all that
rubbish)
At least in C you can come up with a load of helper macros.
And did you try and use COM in the delphi 1 days? It was utterly mad.
People made it work and THEN gave up.
I use Delphi from its first Version under Win3.1. And of course I have
already used COM Objects.
That was one of the reason I don't like the windows platform.
About COM Objects, I agree, you want variants
Variants let the programmer concentrate on the meaning of the code
when
integrating with other systems. Often the overhead of what was being
controlled was nothing to the overhead of the variant (and of course,
this was being managed by hand in Delphi 1 anyway). And the overhead
of
writing code with variants was much less than writing code that did it
all by hand.
People keep re-inventing COM and variants all over the shop because
they
don't have com and variants when the need them.
Variants are good things but they were not created to allow lazy
programming or implicit convertions. They were made in order to
provide a dynamic type when you can't know the type of the variable
(in SQL queries for example).
Maybe that's why there were made, but they were put into Delphi to
allow implicit conversions from unspecified types from systems that
use
unspecified types, and to let Delphi use easily integrate with systems
that use unspecified types.
There's nothing wrong with an implicit conversion if the generated
code
is pretty much exactly what you would (should) have explicitly
written.
anyway... I think we fully explored other peoples opinions. I think
you
don't like variants because they ways in which I (also) think other
people shouldn't use them are bad.
:)
They are not bad. They have to be used for what they have been created
for :p
Sam
--
Damien Gerard
[EMAIL PROTECTED]
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] The use of Variants?
On Tue, Nov 13, 2007 at 09:47:31AM +0200, Graeme Geldenhuys wrote: What are your feelings about the use of Variants? I'm debating this in another NG and would like some outside opinion. Use for what? My personal opinion on Variants: * I don't like them. [if that's a reason] :-) * They seem like a bit of a hack. Native types seem to be a better solution to me, even though it might end up being a bit more work (coding wise). * They tend to be slow compared no native types. In Delphi 6 they were very slow. How does it compare in FPC 2.2.0? Variants are mainly interesting when communicating with foreign entities that are not typefast. Being generic database support (allows to have generic code to talk to databases, without having the database layout in some structure form compiled in), COM support, or PHP (www.stack.nl/~marcov/phpser.zip ) They were never meant to be used as normal variables. _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] The use of Variants?
On 13/11/2007, Marco van de Voort [EMAIL PROTECTED] wrote: On Tue, Nov 13, 2007 at 09:47:31AM +0200, Graeme Geldenhuys wrote: What are your feelings about the use of Variants? I'm debating this in another NG and would like some outside opinion. Use for what? In tiOPF we have a Criteria unit that generates SQL 'where' clauses as output. Currently that unit isn't used much - its still in the development stages. My initial implementation only uses string types - probably because my test app used TEdit text boxes as input and that the required criteria output must always be in string format anyway. So all methods handle strings parameters only. We now received a patch which uses variants to support multiple types like floats, dates etc... The tiOPF project is normally against using Variants, so I hesitated to commit the patch. So asked the question here, what others think of variants. eg of changes in patch... -procedure AddBetween(AAttribute, AValue_1, AValue_2: string); +procedure AddBetween(AAttribute: string; AValue_1, AValue_2: variant); -procedure AddEqualTo(AAttribute, AValue: string); overload; -procedure AddEqualTo(AAttribute: string; AValue: integer); overload; +procedure AddEqualTo(AAttribute: string; AValue: variant); overload; TPerBetweenCriteria = class(TPerValueCriteriaAbs) private -FValue_2: string; +FValue_2: variant; public -constructor Create(AAttribute, AArg_1, AArg_2: string; ANegative: boolean = false; AFieldName: string = ''); reintroduce; virtual; +constructor Create(AAttribute: string; AArg_1, AArg_2: variant; ANegative: boolean = false; AFieldName: string = ''); reintroduce; virtual; functionGetClause: string; override; published -propertyValue_2: string read FValue_2; +propertyValue_2: variant read FValue_2; end; They were never meant to be used as normal variables. That's what I thought. And from the above patch snippet, I can't see variants being justified. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] The use of Variants?
* Graeme Geldenhuys wrote, On 13/11/07 12:39: On 13/11/2007, Marco van de Voort [EMAIL PROTECTED] wrote: On Tue, Nov 13, 2007 at 09:47:31AM +0200, Graeme Geldenhuys wrote: What are your feelings about the use of Variants? I'm debating this in another NG and would like some outside opinion. Use for what? In tiOPF we have a Criteria unit that generates SQL 'where' clauses as output. Currently that unit isn't used much - its still in the development stages. My initial implementation only uses string types - probably because my test app used TEdit text boxes as input and that the required criteria output must always be in string format anyway. So all methods handle strings parameters only. We now received a patch which uses variants to support multiple types like floats, dates etc... The tiOPF project is normally against using Variants, this interesting if it is a blanket policy, unless it is a blanket policy against the blanket use of variants :=) so I hesitated to commit the patch. So asked the question here, what others think of variants. eg of changes in patch... -procedure AddBetween(AAttribute, AValue_1, AValue_2: string); +procedure AddBetween(AAttribute: string; AValue_1, AValue_2: variant); -procedure AddEqualTo(AAttribute, AValue: string); overload; -procedure AddEqualTo(AAttribute: string; AValue: integer); overload; +procedure AddEqualTo(AAttribute: string; AValue: variant); overload; TPerBetweenCriteria = class(TPerValueCriteriaAbs) private -FValue_2: string; +FValue_2: variant; public -constructor Create(AAttribute, AArg_1, AArg_2: string; ANegative: boolean = false; AFieldName: string = ''); reintroduce; virtual; +constructor Create(AAttribute: string; AArg_1, AArg_2: variant; ANegative: boolean = false; AFieldName: string = ''); reintroduce; virtual; functionGetClause: string; override; published -propertyValue_2: string read FValue_2; +propertyValue_2: variant read FValue_2; end; I think that removing the non-variant overloads is un-necessary. They were never meant to be used as normal variables. That's what I thought. And from the above patch snippet, I can't see variants being justified. Certainly the patch itself does not justify use of variants, but it's the use that would justify it, not the implementation. What did the contributor have in mind, what was the problem being solved? Only that can say whether or not use of variant is justified. However, removal of the non-variant implementations was certainly overkill, IMHO ...and I thought we were talking about whether or not fpc/lazarus should retain variants as a feature - if only you had explained... Sam
Re: [lazarus] The use of Variants?
On 13/11/2007, Sam Liddicott [EMAIL PROTECTED] wrote: The tiOPF project is normally against using Variants, this interesting if it is a blanket policy, unless it is a blanket policy against the blanket use of variants :=) tiOPF does contain variants in code, we are just trying to minimize it's usage and replaced a lot before. In a previous version of tiOPF (when we still supported Delphi 6), the timing unit tests showed exactly how much slower variants were, even compared to other Delphi versions like 5 and 7. However, removal of the non-variant implementations was certainly overkill, IMHO Good point. ...and I thought we were talking about whether or not fpc/lazarus should retain variants as a feature - if only you had explained... :-) Sorry if my intentions were unclear and misleading the thread. This is the description of the patch included in the email. Not sure if attaching the actual patch would make sense, so left it out. The snippet I quoted before got the point across, I think. -- The attached patch does the following: oChanged Criteria to use variants instead of strings, so it can cope with more data types (ie floats, dates etc) oChanges Criteria to generate sql with params instead of string oAdded TtiQueryParams.SetValueAsVariant to make code cleaner ounit tests for above -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] The use of Variants?
Marco van de Voort wrote: Being generic database support (allows to have generic code to talk to databases, without having the database layout in some structure form compiled in), COM support, or PHP (www.stack.nl/~marcov/phpser.zip ) They were never meant to be used as normal variables. Quite agree. It is hard to see how you could do database support without them, with out using truly ridiculous levels of overloading. I can't see any (sensible) way of doing a key search on a complex key without passing an array of variants. On the the other hand, I never use them if I can avoid them. For example, I would always typecast a TField to a specific field type and use the value property rather than use the AsVariant property of a generic TField if I knew the Field type. cheers, John Sunderland _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] The use of Variants?
Variants can be NULL. That's a great thing. 2007/11/13, Graeme Geldenhuys [EMAIL PROTECTED]: Hi, What are your feelings about the use of Variants? I'm debating this in another NG and would like some outside opinion. My personal opinion on Variants: * I don't like them. [if that's a reason] :-) * They seem like a bit of a hack. Native types seem to be a better solution to me, even though it might end up being a bit more work (coding wise). * They tend to be slow compared no native types. In Delphi 6 they were very slow. How does it compare in FPC 2.2.0? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives -- Atenciosamente, Alexsander da Rosa
Re: [lazarus] The use of Variants?
On 13/11/2007, Alexsander Rosa [EMAIL PROTECTED] wrote: Variants can be NULL. That's a great thing. We already have NULL support in tiOPF without the use of variants! Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] The use of Variants?
How does it work? 2007/11/13, Graeme Geldenhuys [EMAIL PROTECTED]: On 13/11/2007, Alexsander Rosa [EMAIL PROTECTED] wrote: Variants can be NULL. That's a great thing. We already have NULL support in tiOPF without the use of variants! Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives -- Atenciosamente, Alexsander da Rosa
Re: [lazarus] The use of Variants?
On 13/11/2007, Alexsander Rosa [EMAIL PROTECTED] wrote: How does it work? You can download and view the code from SourceForge. Or go to the tiOPF website and get links from their. http://www.tiopf.com The unit of interest or standing point would be Source/Core/tiObjects.pas Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
RE: [lazarus] The use of Variants?
The websvn link on http://tiopf.sourceforge.net/SourceCodeRepository.shtml Is broken. Sam -Original Message- From: Graeme Geldenhuys [EMAIL PROTECTED] Sent: 13 November 2007 17:44 To: lazarus@miraclec.com Subject: Re: [lazarus] The use of Variants? On 13/11/2007, Alexsander Rosa [EMAIL PROTECTED] wrote: How does it work? You can download and view the code from SourceForge. Or go to the tiOPF website and get links from their. http://www.tiopf.com The unit of interest or standing point would be Source/Core/tiObjects.pas Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] The use of Variants?
On 14/11/2007, Sam Liddicott [EMAIL PROTECTED] wrote: The websvn link on http://tiopf.sourceforge.net/SourceCodeRepository.shtml Is broken. The text shown is correct, but the actual link is still the old one. Thanks, I'll update the website now. Here is the correct link: http://tiopf.svn.sourceforge.net/viewvc/tiopf/ Here is some more information on tiOPF and Lazarus. http://wiki.lazarus.freepascal.org/tiOPF Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
[lazarus] The use of Variants?
Hi, What are your feelings about the use of Variants? I'm debating this in another NG and would like some outside opinion. My personal opinion on Variants: * I don't like them. [if that's a reason] :-) * They seem like a bit of a hack. Native types seem to be a better solution to me, even though it might end up being a bit more work (coding wise). * They tend to be slow compared no native types. In Delphi 6 they were very slow. How does it compare in FPC 2.2.0? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
