Hey guys,
I was hoping to see if we could discuss some of the "final" qualifiers
on some of the methods in the AbstractIOSession. The reason I ask is it
would be cool to be able to override some of the methods such as:
public WriteFuture write(Object message)
public final int getScheduledWriteMe
Jeff Genender wrote:
Hey guys,
I was hoping to see if we could discuss some of the "final" qualifiers
on some of the methods in the AbstractIOSession. The reason I ask is it
would be cool to be able to override some of the methods such as:
public WriteFuture write(Object message)
public final
I like it (the assert) ;-)
But I am not sure about having a completely different
AbstractIOMockSession since we would then be copying code to a certain
degree. I think it would just be cleaner to have the methods protected
so there is no need for code duplication ;-)
What do *you* think? ;-)
Jef
Jeff Genender wrote:
What do *you* think? ;-)
Beside the assert, which was a side effect of my quick glance at the
method you want to override, I think that dooming the final is sane.
If someone needs to protect this method, then the best solution would be
to define a super class with fin
Hi Jeff and Emmanuel,
You can add some hook for IoSession.write() by inserting an IoFilter,
so I am not sure about removing the final modifier from write().
Overriding getScheduledMessages and getScheduledBytes makes sense
though because they will always be 0 because messageSent event will be
alw
Alternatively, we could add a protected method in AbstractIoSession
and make write() method to call it before returning. However, it is
essentially the same with adding an IoFilter IMHO.
The implementation of IoSession and IoFilterChain is not so trivial so
creating another mock object is a kind
I agree...this makes sense...Filter is the way to go.
Jeff
Trustin Lee wrote:
> Alternatively, we could add a protected method in AbstractIoSession
> and make write() method to call it before returning. However, it is
> essentially the same with adding an IoFilter IMHO.
>
> The implementation o
Trustin (and others)...so how about these changes and additions to the
AbstractIoSession? This will allow the scheduledBytes/messages to be
overriden, and also allow someone to set them.
Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
==
Hi Jeff,
Do we need to remove the final modifier if we are going to provide
setters? And assuming you are using DummySession as a mock object,
I'd suggest making AbstractIoSession.setScheduled...(...) protected
and make them public in DummySession. WDYT?
Cheers,
Trustin
On Dec 28, 2007 8:19 AM
Yep...agreed...how is this?
Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
===
--- core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(revision 607135)
+++ core/src/main/java/org/apache/mina/comm
2/docs/guide/lang/assert.html#usage
(See first point!)
regards and a happy new year,
Steve
--
View this message in context:
http://www.nabble.com/AbstractIoSession-and-final-qualifiers-tp14507695s16868p14574728.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
unit tests of code. Any thoughts on
> making these protected instead of final?
>
No, protected is wrong. I want to call the write method from another class
in another package so it must be public. ;-)
regards
Steve
--
View this message in context:
http://www.nabble.com/AbstractIoSessio
Steve Ulrich (proemion) wrote:
Emmanuel Lecharny-3 wrote:
Wouldn't be a perfect case for an assert ? Like :
public final WriteFuture write(Object message, SocketAddress
remoteAddress) {
assert message != null : "Null messages are not allowed";
...
wdyt ?
NO!
13 matches
Mail list logo