Suggestion on Channel Classes

["이희승 (Trustin Lee)"]

Hmm, I'm not sure yet why such a design is not a good idea.  Isn't it
what Java interface is for?  Anyway, the problem is that it's difficult
to understand the large picture of class hierarchy at a glance, and we
need to fix it.

Those interfaces were introduced to:

  * determine the underlying transport of the channel easily
    (e.g. instanceof SocketChannel? instanceof DatagramChannel?)
  * leverage covariant return types
    (same applied to various ChannelFactory subtypes)

What's interesting is that a user does not (and does not need to) know
the existence of all these interfaces actually in many cases.  They are
mostly for advanced user's convenience.  Therefore, I think we don't
really need to over-expose the complicated class hierarchy when
introducing Netty to a beginner.

However, well drawn diagrams will help a developer that tries to
understand the internals of Netty quite a lot.  We do not have a
developers guide yet, so it will be a great addition to Netty
documentation and your diagrams will be very useful for such purpose.

Firstly, let me try to reduce the complexity of APIviz diagrams in
Javadoc so that a user doesn't get lost in a cluttered diagram.  We
could continue the discussion on making the Netty internals easier to
understand on the other hand as a separate documentation effort.  WDYT?
I'm open to good ideas.

Thanks,
Trustin

On 07/16/2009 01:02 AM, Mike McGrady wrote:
> My point should have been thought through to a greater degree.
> 
> Essentially, however, I noticed that in effect some classes
> systematically are "extending" or "implementing" the same interface from
> more than one direction, e.g., extending a class that implements an
> interface and implementing an interface that extends the same
> interface.  This does not look good to me and I came up with a too
> rushed solution.  Not sure what should be done.  I am most interested in
> your first suggestion.
> 
> Mike
> 
> On Jul 14, 2009, at 11:38 PM, 이희승 (Trustin Lee) wrote:
> 
>> On 07/15/2009 03:29 PM, 이희승 (Trustin Lee) wrote:
>>> Hi Mike,
>>>
>>> On 07/07/2009 08:14 AM, Michael McGrady wrote:
>>>> The Netty Channel interface throughout the package uses the following
>>>> design pattern.
>>>>
>>>> The sub-interfaces are seemingly wholly unnecessary and over-complicate
>>>> understanding the design. This is seemingly true of all of the
>>>> following
>>>> interface extensions.
>>>>
>>>> Unless there is good reason to the contrary that I am not aware of, I
>>>> would deprecate these extensions and then get rid of them.  I would not
>>>> be surprised if I have missed some reason why these are necessary.
>>>
>>> I'm not sure I understood what you suggested correctly, but are you
>>> suggesting to remove the channel interfaces that extends one or more
>>> other channel interfaces?  If so, I agree.  For example,
>>> LocalServerChannel should be replaced by the combination of LocalChannel
>>> and ServerChannel.  The same change could be applied to
>>> ServerSocketChannel and XnioServerChannel.  Let me know if this is what
>>> you think (or not.)
>>
>> Or, did you mean XYZServerChannel doesn't need to extend XYZChannel?
>> (e.g. LocalServerChannel does not extend LocalChannel)  It actually
>> sounds more reasonable.
>>
>> Trustin
>> _______________________________________________
>> netty-dev mailing list
>> netty-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-dev
> 
> Mike McGrady
> Principal Investigator AF081-028 AFRL SBIR
> Senior Engineer
> Topia Technology, Inc.
> 1.253.720.3365
> mmcgrady at topiatechnology.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> netty-dev mailing list
> netty-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-dev