Rafal...keep the discussion on the Turbine list pls. :-) on 1/23/01 2:26 AM, "Rafal Krzewski" <[EMAIL PROTECTED]> wrote: > Is there any reason not to have setConfirmed(boolean) to accompany > boolean isConfirmed()? > It can be done just fine with setConfirmed(String) but > setConfirmed(true) just looks > better :-). The reason is that it doesn't make sense that way. I thought long and hard over this one. setConfirmed not a boolean operation, it is a String operation. The String value is either the confirm value or a random string, it isn't a confirm value or "" except when you aren't implementing this functionality. I would rather have it make sense for people who implement it vs. people who don't. :-) This is the one thing that I'm going to put my foot down on and stand up for...i really think it needs to be this way... :-) <smile> :-) the only thing that doesn't make sense is the name of the method call as being "setConfirmed/getConfirmed"...but it is following the name of the database column so that is why it is that way...if the column name was CONFIRM_VALUE, the method names would probably make more sense...ie: setConfirmValue/getConfirmValue... thanks, -jon ------------------------------------------------------------ To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/> Problems?: [EMAIL PROTECTED]
