channelRead0 is a stupid name (SimpleChannelInboundHandler)

[md-5]

We had messageRecived, now we have channelRead0... the name seems REALLY internal and specific.

[trustin]

I agree. Couldn't find a good alternative though. Now that the public API is not easy to change, we have to live with it. :-/

Sent from a mobile device.
https://twitter.com/trustin
https://twitter.com/trustin_ko
https://twitter.com/netty_project

-----Original Message-----
From: md-5 notifications@github.com
To: netty/netty netty@noreply.github.com
Sent: Wed, 17 Jul 2013 11:08 AM
Subject: [netty] channelRead0 is a stupid name (SimpleChannelInboundHandler) (#1590)

We had messageRecived, now we have channelRead0... the name seems REALLY internal and specific.

---

Reply to this email directly or view it on GitHub:
#1590

[md-5]

Sorry, cross posted across issues,surely messageReceived would be adequate? Maybe for 4.1?

[He-Pin]

messageReceived or channelMessageRead both okay,the channelRead0 style is used in internal.

[md-5]

the channelRead0 style is used in internal.
Yeah thats my point :)

[He-Pin]

@md-5 I don't like that too,for trustin,i don't think that many user has convert to netty 4 and treat netty4.0.0-final as final.
and if still keep the channelRead0,then will have an endless pain for the user~:P
I promote +1 to change it.

[md-5]

As someone who has used Netty 4 in 2 production applications since Alpha1, I feel that the jump to Final was WAY too quick given the scope of the changes since ~CR8 (which I currently use) -> Final. I feel that there should have been more community involvement before it was given the OK.

[md-5]

Also I vote for messageReceived so it matches everything else

[He-Pin]

@md-5 as I can see,no Chinese coder will send the full request ,open issue or tracking it,even most mobile game company using netty,them like to use QQ group to exchange their experience,so I think,netty is really need more community involvement.
all in all,I vote for messageReceived cause it's more unintuitive just like netty3.

First the channelInboundUpdated then MessageReceived in CR5 and now channelRead;
cause there is an channelRead method in the ChannelInboundHandlerAdapter,so trustin make an hard
decision and choose channelRead0 to make it different.

[jpinner]

@trustin & @normanmaurer -- In the previous CRs, was the object autoreleased after the messageReceived call?

If the answer is yes and the behavior is the same, then I am OK with renaming this method back to messageReceived if that's what you decide to do.

If the answer is no and the autorelease behavior is new, then I don't think we should reuse the old name with different behavior.

[md-5]

@jpinner
SimpleChannelInboundHandler will autoRelease by default.

[normanmaurer]

@md-5 @trustin @jpinner if we really want to get rid of channelRead0(..) we should do the following:

• deprecated SimpleChannelInboundHandler
• Add a new handler which does exactly the same as SimpleChannelInboundHandler but use different methodname then channelRead0(...). We could even let it just extend SimpleChannelInboundHandler and surpress the deprecation warning
• Remove SimpleChannelInboundHandler in 4.1.0 or 4.2.0

[jongwook]

I completely agree with the title. I almost gave up the migration when I saw the name.

[cgbystrom]

I found the name a bit confusing as well.

[trustin]

Instead of introducing another handler class with an obscure name, I'd like to just break the compatibility because we are working on 5.0 already.

[normanmaurer]

@trustin you are refer to my comment here ?

[trustin]

Yeah.

[normanmaurer]

Sure we can do this… What you think would be a good one ?

Am 02.11.2013 um 12:04 schrieb Trustin Lee notifications@github.com:

Yeah.

—
Reply to this email directly or view it on GitHub.

[trustin]

Ugh, I meant it isn't worth doing that at this stage. As you see I just renamed channelRead0 to messageReceived, and updated the Javadoc.

[normanmaurer]

@trustin I see... works for me ;)

[avinayak]

thank you