On Wed, Oct 26, 2011 at 11:11 AM, Charles Oliver Nutter <head...@headius.com> wrote: > On Wed, Oct 26, 2011 at 11:05 AM, Nick Sieger <nicksie...@gmail.com> wrote: >> Looks good for the most part. Two things I'd like to see: >> >> 1. Put the descriptions in javadocs for each field. API docs are going >> to be more popular for browsing the full set of configuration options. >> Does the description/toString ever get used in a meaningful way? > > That's not a bad thought, though I'm not sure how best to get those > descriptions into --properties. The description you see there is > automatically being composed into our command-line --properties > output. That was one goal of this...to have property metadata and > description all in one place, so we could generate doco and handle > property loading all from the same structure. > >> 2. Do away with the static-ness of the fields. Can we get away with >> them being instance variables and a Properties-instance-per-runtime? >> I'd rather see that approach with a fallback to a statically loaded >> value. That would allow different runtimes in the same JVM to be >> configured differently, either through updating system properties or >> via an API that gives access to the Properties object (that was the >> original intent for RubyInstanceConfig). > > The Properties object may be a bit misleading. It doesn't actually > have any state. The Property objects are just metadata + load logic > for the various config properties, and the values they load are stored > elsewhere...some are instance fields on RubyInstanceConfig and some > are still statics, but I didn't change anything on that end of things > yet. This commit *only* centralizes the load logic and metadata. > >> One final mention -- naming the class Properties clashes with >> java.util.Properties too easily for me. > > Yeah, I agree. Trying to think of a better way to describe it. > PropertyMetadata or something? MetaProperties? It's not really a > "Properties" object at all, since it has no state.
Option? -Tom > > - Charlie > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.en...@gmail.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
