Hi Rich,
At 14:47 22.02.2001 -0800, Richard Trevor wrote:
>Hi,
>
>I had inquired about a get(...) feature several weeks ago. I'm happy to see
>that it is in the works!
It has actually been already implemented by Anders! It's there today.
>I have no problem with the bean-like getX, setX interface, but it seems to me
>that in a non-bean world, the setOption, getOption, getOptionStrings interface
>would be much more useful.
Why do you think so?
The bean paradigm provides information on the type of the option values. The
getOption/setOption approach does not give you info on the value type. Moreover, the
java beans have provision for finding editors for a given type, e.g. we could write a
PriorityEditor for graphically manipulating priorities.
Java Beans just give us more room to maneuver. Beans are also non-intrusive. It's
pretty brilliant stuff IMHO.
>Is it a big deal to support both interfaces? I guess I don't understand the downside
>of putting out the ...Option interface. (Other than cluttering up the API, I guess).
>Correct me if I'm wrong, but if you are not in a bean environment, you'd have to do
>some
>work to figure out all the get(...) methods to call...
Yes, unfortunately it is a big deal. It is 2 times the number of options in all
appenders. Assuming there are 15 appenders with 3 options on average, that gives 45
more things to worry about. That is definitely not acceptable. It's one way or the
other but not both. Cheers, Ceki
-----Original Message-----
>From: Ceki Gülcü [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]]
>Sent: Thursday, February 22, 2001 2:25 PM
>To: LOG4J Users Mailing List
>Cc: anders Kristensen
>Subject: Re: Why more set(....) APIs than get(....) APIs in log4j ?
>
>At 22:01 22.02.2001 +0100, Anders Kristensen wrote:
>>Jin,
>>
>>Funny you should ask, because the getters you ask for have actually been
>>applied to the log4j version in the CVS repository and will be included
>>in the next release. However, we've been discussing the option of
>>changing the current option OptionHandler configuration strategy from
>>something based on
>>
>> void setOption(String key, String value) { ... }
>> String getOption(String key) { ... }
>> String[] getOptionsStrings()
>>
>>to something based on regular Java setters and getters, e.g.
>>
>> void setFilename(String name)
>> String getFilename() { ... }
>>
>>and then use a Beans-like strategy or reflection or something to figure
>>out which parameters a log4j component knows about. That seems to be a
>>better approach but requires a bit more work.
>>
>>Anders
>
>Anders,
>
>I think that the getX/setX or bean paradigm is more widely accepted. We should
>probably go with that. The getOption methods are cool except that if they go into an
>official release it will damn hard to take them back. So if we decide to switch I
>think we should switch as soon as possible. I actually intend to release 1.1beta
>before this weekend though that is not a promise... What do you think? Ceki
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: [EMAIL PROTECTED] (preferred)
CH-1005 Lausanne [EMAIL PROTECTED]
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
