Hi Rob,
Months ago, I suggested using [functor] for such a purpose. Don't know if you remember. Here's a quick link: http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=104730670828791&w=2 And you may still provide standard type checkers and converters using the proposed framework. I understand that [functor] would add another dependency to [CLI]. But it could easily become a "soft dependency" (required to build but not necessarily to run). The main problem is (IMHO) that [functor] is still in the sandbox and thus there's no official binary release (yet). Regards, Herve On Tue, 12 Aug 2003, Rob Oxspring wrote: > I'd envisaged the conversion String->Integer to be handled by some IntegerValidator > class attached to the Argument. If this pattern > is chosen then I'm not sure how practical overloaded methods would be - the range of > types that could be returned would be infinite > and we'd have to think about where to draw the line before the number of convenience > methods grows too big. I guess the sensible > place to draw that line would be for the Java primitives as anything else can easily > be cast from an Object anyway. > > Of course this is ignoring the fact that an XML configuration would have the full > knowledge of which types were needed where. To be > honest though I really need to think about the xml2cli thing. I like the idea in > principle but I'm really struggling to get a > handle on what input would be supplied, what might be generated and how the client > code would interact with cli to respond to the > chosen options. The end points are still to blurry in my head to see what > transformation is needed. But I'll switch the xml stuff > to a new thread. > > Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
