As Cyril pointed out, this went to the wrong list.



Pardon my ignorance, but could you sketch out the nature of the problem 
for me?

I ask in particular because the current situation is dirty.  There is a 
lot of talk going on about the plumbing, which is generally over my 
head, but, in the short term I would like to see the Options 
rationalized in the following way:

recognise that Options is currently completely static - aim to make it a 
non-instantiable class.
remove the CommandLineOptions class (use String[] where necessary, and 
integrate the parsing functions into the now static Options class.)
provide an Options.configure static method in a number of guises to 
cover the current use cases.

Of course, you couldn't actually make Options non-instatiable, and you 
couldn't actually remove CommandLineOptions, but you could pretend, and 
provide an alternative to instantiating Options and CommandLineOptions 

I have mentioned in a previous post the setting of user config file in 
the system config.


Jeremias Maerki wrote:

>>So I can call options once (at application start) and it will affect all 
>transformations thereafter?
>>That's nice, as I think I was calling this every transformation.
>Right. Not that I find this overly nice, because using statics can be A
>Bad Thing (TM) in server environments. We're going to change that
>Jeremias Märki
>Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
>Fon +41 41 317 20 20 - Fax +41 41 317 20 29

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to