Berin Loritsch wrote:
We got sidetracked on this issue.
can we just get back on track? We're not really getting anywhere I guess...
Peter Donald wrote:
> Fairly silly if you ask me but I got not choice in the manner.
sure you do. State your opinion and preferences, explain how you formed
thos
> that would imply that there is a remove method...
Yup. :-) Should be one.
> > > does anyone actually know what use case would use multicast?
> > Why have a listener at all?
> Good question - anyone care to answer?
If we can get an answer to mine, we can probably answer yours.
--- No
On Fri, 7 Feb 2003 08:21, Noel J. Bergman wrote:
> If this is something that isn't needed,
It is needed or else I would not have implemented it.
--
Cheers,
Peter Donald
"No. Try not. Do. Or do not. There is no try."
> I think we have entered the "well it depends on your personal
> preferences" zone here. I see your point, and still I think my
> way is better - simply because I give more weight to my own
> arguments for no particular reason other than my own
> sense of aestethics.
LOL
Personally, I was perman
> From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
>
> > Since we should keep the necessity of try/catch to a
> minimum, I figure
> > people can live with a RuntimeException potentially being
> thrown until
> > we can get true multicast functionality in.
>
> So the person calls the method,
On Fri, 7 Feb 2003 08:00, Noel J. Bergman wrote:
> The unicast convention is that you remove the current one, then you can add
> a replacement. At least you know that you've done something "bad."
that would imply that there is a remove method...
>
> > does anyone actually know what use case woul
> Seems like this is already decided. However you have removed the ability
to
> change the listener. At least add that back.
The unicast convention is that you remove the current one, then you can add
a replacement. At least you know that you've done something "bad."
> does anyone actually know
> Since we should keep the necessity of try/catch to a minimum, I
> figure people can live with a RuntimeException potentially being
> thrown until we can get true multicast functionality in.
So the person calls the method, and because they are saving themselves from
the perils of exception handli
Seems like this is already decided. However you have removed the ability to
change the listener. At least add that back.
Fairly silly if you ask me but I got not choice in the manner. The listener is
an abstract class not an interface and is not likely to be ever multicast.
Just as a curious qu
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>
> Leo Sutic wrote:
>
> >
> >
> >>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> >>
> >>void addLoggerListener( final LoggerListener listener )
> >> throws java.util.TooManyListenersException()
> >>{
> >> if ( null == m_loggerL
Leo Sutic wrote:
From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
void addLoggerListener( final LoggerListener listener )
throws java.util.TooManyListenersException()
{
if ( null == m_loggerListener )
{
m_loggerListener = listener;
}
else
{
throw new
>
synchronized void addLoggerListener( final LoggerListener listener )
throws java.lang.UnsupportedOperationException
> UnsupportedOperationException is a RuntimeException and requires no
try/catch
Oh great ... so you want to throw an exception without the compiler telling
me about it. :-)
On Thursday, February 6, 2003, at 12:37 AM, Berin Loritsch wrote:
void setLoggerListener( final LoggerListener loggerListener )
-0
void addLoggerListener( final LoggerListener listener )
throws java.util.TooManyListenersException()
+1
-pete
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> void addLoggerListener( final LoggerListener listener )
> throws java.util.TooManyListenersException()
> {
> if ( null == m_loggerListener )
> {
> m_loggerListener = listener;
> }
> else
> {
>
Stephen McConnell wrote:
Berin Loritsch wrote:
void setLoggerListener( final LoggerListener loggerListener )
-0
-0
Or do we define it as:
void addLoggerListener( final LoggerListener listener )
throws java.util.TooManyListenersException()
+1
+1
- Leo
---
Berin Loritsch wrote:
void setLoggerListener( final LoggerListener loggerListener )
-0
Or do we define it as:
void addLoggerListener( final LoggerListener listener )
throws java.util.TooManyListenersException()
+1
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
h
We got sidetracked on this issue. LogKit 1.2rc5 works with no bugs
reported.
The only outstanding issue before a release is the LoggerListener API.
Do we define the LoggerListener registration as:
//--
void setLoggerListener( fina
17 matches
Mail list logo
