Hi Marius and Tim (and anyone who has an opinion on this). Sorry for not responding earlier. To clarify, there's no question that parseXXX will continue to return a box. The call to the DateFormat's parse method is wrapped in tryo in the default implementation. The real question is if formatXXX should return a Box. The *only* justification for it returning a Box is because the input could be null, and thus the output would be Empty. Now in my understanding the only realistic reason to expect a null input is because these functions are used my Mapped(Date)(Time), whose values can be NULL, a.k.a. null. My opinion, after thinking about it more, is this. In Scala null is generally seen as an undesirable artifact of Java interopability which should be contained in the smallest "area" of code possible. Also, it's easier (though doubtfully smarter) to use null rather than Option when dealing with databases because it's the most 1:1 with the backend format and the most lightweight API. In any case apparently the design decision in Mapper was to represent the data as nullable values. But I don't think this puts the responsibility of dealing with null on ConversionRules. My opinion would be that MappedXXX should have its own way of formatting nulls. What do you think?
------------------------------------- Timothy Perrett<timo...@getintheloop.eu> wrote: +1 on the Box... that is the lift idiom. Cheers, Tim On 15 Jan 2010, at 07:18, Marius wrote: > I'd strongly suggest: > > 1. All should return Box. In case of parsing failure for example > return a Failure. > 2. If a param is null, inside your method use (Box !! param) which > would give you an Empty if param is null. > > We should not assume dumb default values for input that doesn't make > sense. > > Br's, > Marius > > On Jan 15, 4:38 am, Naftoli Gugenheim <naftoli...@gmail.com> wrote: >> As suggested I am with G-d's help working on a new >> net.liftweb.http.ConversionRules object, to contain factories for parsers >> and formatters for date, date-time, time java.util.Date objects. Then >> LiftRules.formateDate and .parseDate would be deprecated I suppose. >> One question is how to deal with null. The LiftRules implementation for >> formatDate replaces null with new Date(0L), and parseDate returns Empty for >> a null input. >> 1. Should these functions worry about null? Maybe it's the caller's >> responsibility, such as net.liftweb.mapper.MappedDate. >> 2. If they should think about null, parseXXX returns a Box anyway because a >> string may not parse, and null certainly doesn't parse and should thus >> return Empty. However how should formatXXX deal with null? Here are some >> suggestions; any others are welcome. >> (a) Return an empty string - "" >> (b) Return something like " (no selection)" etc. >> (c) formatXXX should also return a Box, which would be Empty for null >> (d) Behave as though new Date(0L) was passed in >> (e) Behave as though new Date was passed in > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
