This sounds a bit like a dangerous trap.
1. "The config file should be bare, with no comments whatsoever," reads
to me as "brittle parser". Java has nice XML facilities; are we trapped
in an old version of Java that didn't have them? If not, why aren't we
considering an XML based configuration file?
XML offers distinct advantages, including but not limited to: easier
versioning, validating parser, room for ignorable comments, etc.
2. The whole idea of parameter names and types through a method strikes
me as a property map. If what we're aiming for is a property map, this
abstract class seems to be a property map of the heavily over-engineered
variety. Might as well use java.util.Map and save yourself a forest of
classes.
If we're not aiming for a property map, then the design strikes me as a
design without a context. That is, a design where we know what we're
modeling but not how it will be used. So, we invent a base class with a
ton of methods that must be implemented and throw unchecked exceptions
like ClassCastException because the try { } catch blocks necessary for
checked exceptions will get old really fast.
If you can't get a handle on the context, at least consider using
Integer.parseInt() and Double.parseDouble() at the point of conversion,
rather than pushing the conversions into a class. True, they throw an
unchecked NumberFormatException, but the semantics in the failure case
are crystal clear; I can't say the same for a ClassCastException that's
the result of state outside the class itself.
Just my one rupee...
Patrick
Ian Clarke wrote:
>
> On 1 Feb 2006, at 13:40, Matthew Toseland wrote:
>
>> Soon we will need config support for 0.7. The plan is to have the format
>> roughly the same, but with some functional changes. However I think
>> there are some unclear issues, so I am posting before I code it.
>>
>> Expected functional changes:
>> - When you register a config option, you have to include a callback
>> object. So most options will now be updatable on the fly, rather than
>> the occasional option being updatable on the fly.
>
>
> I think we would have an abstract class something like this that would
> need to be implemented for each parameter:
>
> public abstract class Parameter {
> public abstract String getShortName();
> public abstract String getLongName();
> public abstract String getDescription();
> public abstract Class getParamType();
>
> public String getString() throws ClassCastException {
> return (String) get();
> }
>
> public String getInt() throws ClassCastException {
> return ((Integer) get()).intValue();
> }
>
> // ...Ditto for getting other types...
>
> public abstract Object get();
>
> public String getAsString() {
> return get().toString();
> }
>
> public abstract void setToString(String value) throws
> InvalidParameterException;
> public abstract void set(Object value) throws InvalidParameterException;
> }
>
> Implementations of this abstract class would then be registered with
> the config/command-line system. The implementation of the set() method
> will need to be smart enough to deal with being called more than once.
>
>> So I
>> have come to the conclusion that the config file should be bare, with no
>> comments whatsoever.
>
>
> In the interests of expediency, I can agree to this - although we may
> want to allow for comments in the future.
>
> Ian.
>
>
> _______________________________________________
> Tech mailing list
> Tech at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
>
>
