Rob van Maris <[EMAIL PROTECTED]> wrote: > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Michiel Meeuwissen > > > > I think that I understand now that it returns a String > > because it is stored as String (probably because in the > > resulting SQL query you finally need a String). But it is a > > bit confusing because you set a Number and get a String. > > Yes, but in addition to this, the value can itself be a string. > These are all valid constraints that can be represented: > name BETWEEN 'a' AND 'f' > name BETWEEN '1' AND '5' > number BETWEEN 1 AND 5 > > The same goes for FieldValueInConstraint.
Yes, as I understand it now, the set- on these kind of contraints does a check if you actually set something of the right type into it (must accord with the type of the field). You may for example not provide "1" but must provide Integer(1) on a BetweenConstraint on a field of type integer. This does make sense. But the get- still returns String. So you cannot set something back which you've got... Somehow it seems a bit inconsistent that the object does not obey its own strictness. public BasicFieldValueBetweenConstraint setLowerLimit(Object lowerLimit); public String getLowerLimit(); > > > So, my question is, would it nog have been nicer to store the > > originally set objects rather then converting them to String > > immediately? Then the 'get' functions can work more > > intuitively and cloning will be simpler. > > As far as storing the values is concerned, this is merely a matter of > implementation, chosen to avoid having to do the conversion each time > the get-method is called. Ok, so it seems to me that a bit of consistency in the interface is sacrified for the sake of performance here? Btw is the toString actually called less, or only earlier? > If life is made easier by storing the original objects as well, go ahead > and do it. As long as the interface methods are not affected - these > should return strings. Why should they not return Object? I think the user of the get-method should decide if it has to be a String and not the method itself? I understand that it is targeted at making SQL of it, so probably there is only room for strings. But I wouldn't be sure of that even. Perhaps you could imagine that the SearchQuery object is used to fill the arguments of a stored procedure, which might need other objects then String? Well, anyway, I think I worked around it now, and have no problem with it any more, but still... just wondering. Michiel -- Michiel Meeuwissen Mediapark C101 Hilversum +31 (0)35 6772979 nl_NL eo_XX en_US mihxil' [] ()
