On Mon, 28 Mar 2005 17:13:34 -0800, Shinobu Kawai <[EMAIL PROTECTED]> wrote: > Hi Nathan, > > > > - List support for all the existing methods. Cloning a List returns > > > an ArrayList with the same elements because I couldn't think of a way > > > to make a clone from an arbitrary List. > > > > if you want to really make a thorough attempt at a true clone, you > > might follow the basic pattern that LinkTool.duplicate() does. (try > > clone(), try to get a new instance of the same class, then give and > > use a simple instance like ArrayList) > > clone() isn't public in List, so I guess I'll need to skip the first > step.
oh yeah. hmm. so why are we putting it in this tool by default? is this something you are (or someone else is) using (or has requested)? if not, then i think we shouldn't be trying to implement it yet. YAGNI, ya know? > Or should I just go ahead and use reflection? I really don't > like reflection that much, because it makes everything so complicated. > But I guess it's fine if it's hidden inside a tool. yeah, reflection is pretty heavily used in Velocity; i don't think we should be too afraid of it in tools. *if* we're gonna keep this method, that is. :) > > > - size() method. Does the same thing as the length() method. > > > > hmm. if we're generally trying to hide the difference between Lists > > and arrays in templates, i think we should pick one of these and drop > > the other. i'm thinking size() is the one to keep. > > Well, if _I_ were to keep only one, it would be size(), too. > > Which brings up another question: Do we want support for other List > methods, like contains() and isEmpty()? (These two are the only ones > I've ever called from a template.) good question. and i think the answer is yes. i don't use contains() much, but i do use $list.isEmpty() a lot. if we're gonna offer this as (among other things) a way to hide the difference between arrays and lists in a template, then we should probably support these. > > i would prefer to see the list(obj) and array(obj) methods follow the > > pattern of type-conversion methods in the other tools and be called > > toList() and toArray(). > > That'll be easy. :) > > > also, out of curiousity, in your toList() method, why don't you just > > use java.util.Arrays.asList()? is Eric Fixler's refactoring superior > > for some reason? > > Arrays.asList() only works for Object arrays. We might be getting > primitive arrays as well. I used to have a whole bunch of > instanceof's. ah. yeah, that makes sense. i figured i was missing something. my only question, then, is should we have this return fixed-size lists like Arrays.asList() does? honest question. my first instinct is to say that it should, but i'm really not sure if that's important (or even just worth the effort) here. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
