> I've never liked to use Integer. Is it really the > better design choice ? and why ? Is it the
Not for all situations. But the simple fact is that a primitive cannot represent NULL state without using a "magic number". Magic numbers are (to the best of my experience and education) NEVER a good idea. Hence, you're better off with an Integer than a "magic int". >From a practical perspective, Integers are better because they are objects and can take part in Object features. For example, you can use them in a collection or pass them as a parameter to your SQL Maps. If you're lucky enough to use J2SE 5, then this is less important...but trust me, primitives are no less of a problem in J2SE 5. >From a purely academic sense, Java is a hybrid language. A Smalltalk developer would tell you to avoid primitives like the plague. A C developer, would tell you primitives are the only way to go. Generally speaking, Java is more OO than not, so the Smalltalk developer would probably be correct more often than the C developer. All I can say is...dude, you'd love Ruby. ;-) Clinton On Sat, 05 Feb 2005 14:04:19 +1100, Huy <[EMAIL PROTECTED]> wrote: > Clinton Begin wrote: > > You guys have to understand that this is a tough call for us. It's > > just such a horrible implicit behaviour that I can't even imagine the > > concequences of it. > > > This falls into the category of: "Feature to support bad design choices." > > > > Regardless of whether you have control over the database or not, you > > seem to have control over two other things: > > > > 1) The JavaBean design - You can solve the problem by using Integer > > instead of int (a good design choice). > > I'm going a bit OT here, but I'm really interested in this point. I'm > not exactly a very experienced java programmer but I've never liked to > use Integer. Is it really the better design choice ? and why ? Is it the > null thing or is because it makes everything more consistent in terms of > being objects. > > > - OR - > > > > 2) The SQL Maps - You can solve the problem by specifying nullValue > > attribute of the result mapping (an explicit behaviour and a good > > design choice). > > I guess explicit is always better, but I'm a lazy programmer sometimes > ;-) that's one of the reasons why i use SQL Maps, it does so much for me > automatically (if not automagically). > > Regards, > > Huy > >
