A quick glance at your homepage, and a read of this discussion are enough to convince me to vote -1 to adding this to [lang].
The task [lang] has is to hit a very delicate and fine sweet spot of basic and missing useful JDK-style functions. It should have no framework tendencies, and no great cause to grow. jestr breaks the goals of lang on grounds of: - size - dependencies - potential to grow - 'extensible' (Lang includes ToStringBuilder mainly because HashCodeBuilder got written. The other three classes then naturally followed. ToStringBuilder could do with a small enhancement to enable subclasses to format objects being output, but it certainly isn't a general stringifying mechanism.) Now, having said all of that, jestr looks quite nice and organised and flexible. It could form a separate commons project. It could provide alternative implementations/plugins to the [convert] project. Stephen ----- Original Message ----- From: "David Gilliland" <[EMAIL PROTECTED]> > >What's in IO/Collections that you can't do without for Jestr? > > > Looking at it again, I'm not using those as much as I had thought. In Collections I make one use of DualHashBidiMap, a few uses of IteratorChain, and in IO I use NullOutputStream. I do use Logging quite heavily though. > > But going forward I'd like to incorporate the JXPath stuff for predicates. I think it would be highly cool to be able to give an XPath expression and say "for all nodes in my object graph that match this expression, I want such-and-such stringification style". To reference JXPath from Lang would obviously not be acceptable. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
