* 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; > function GetClause: string; override; > published > - property Value_2: string read FValue_2; > + property Value_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
