My point :) is that introducing a visitor interface that depends on all transport modules doesn't sound good to me. If we are going to do that, the visitor interface will have to be provided as a separate module that depends on all other transport modules to avoid a cyclic dependency. We had a similar problem in TransportType in MINA 1.x related with cyclic dependency.
2008-02-16 (토), 00:21 -0500, Adam Fisk 쓰시길:
> Hmmnn...I don't think so. As far as I can tell, he's talking about
> adding more types to a future MINA release. That would mean adding a
> method to each new type -- hardly a high cost given the return. If
> you want to make it possible for users to add types, you could simply
> have an "visitGenericType" method that would be no worse than the
> current situation, but it doesn't seem like users adding their own
> types would ever be a common use case.
>
> -Adam
>
>
> On Feb 14, 2008 8:53 AM, David M. Lloyd <[EMAIL PROTECTED]> wrote:
> > I believe that Trustin's point is that the visitor pattern is only
> > effective if you know all the visitable types ahead of time. It's quite
> > difficult for a user to wedge in their own type after the fact - they
> > would have to modify the visitor interface for each new transport type
> > they add.
> >
> > - DML
> >
> >
> > Adam Fisk wrote:
> > > I actually think that's exactly why the visitor pattern is nice -- the
> > > more transports you have, the better it gets because you can elegantly
> > > deal with the additional types rather than resorting to instansofs.
> > > The double-dispatch method calling is also a bigger performance boost
> > > the more types you have (as opposed to more "else if"s with the
> > > instanceof approach).
> > >
> > > A visitor itself can also do all sorts of things other than just
> > > identify the type.
> > >
> > > That said, it's really a cosmetic difference either way and barely
> > > worth the discussion -- your time is certainly better spent elsewhere!
> > >
> > > -Adam
> > >
> > >
> > > On Feb 13, 2008 11:58 AM, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote:
> > >> I am not sure if it's a more flexible solution considering we are going
> > >> to have more transports. For example, we have serial port communication
> > >> transport, and we will have to add a visit method per each transport.
> > >>
> > >> Trustin
> > >>
> > >> 2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
> > >>
> > >>> This would be a nice place for the good old visitor pattern, so
> > >>> something like, in SocketSession,
> > >>>
> > >>> SocketSession implements VisitableSession
> > >>>
> > >>> ...
> > >>> public void accept(final SessionVisitor visitor)
> > >>> {
> > >>> visitor.visitSocketSession(this);
> > >>> }
> > >>>
> > >>> Then you have a lot of flexibility with the visitor itself to handle
> > >>> types nicely. The SessionVisitor would be an interface like:
> > >>>
> > >>> public interface SessionVisitor
> > >>> {
> > >>> void visitSocketSocket(final SocketSession session);
> > >>> void visitDatagramSession(final DatagramSession session);
> > >>> }
> > >>>
> > >>> I'd be happy to make a patch along those lines if people were
> > >>> interested. It would use generics for return types rather than the
> > >>> above for slightly more flexibility.
> > >>>
> > >>> -Adam
> > >>>
> > >>>
> > >>> On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote:
> > >>>> 2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
> > >>>>> Hello ,
> > >>>>> i have same doubt..
> > >>>>> - How can I tell if the connection is udp or tcp?
> > >>>> In 1.x, you can use IoSession.getTransportType(). In 2.x, you can
> > >>>> simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.
> > >>>>
> > >>>> --
> > >>>> what we call human nature is actually human habit
> > >>>> --
> > >>>> http://gleamynode.net/
> > >>>>
> > >>>
> > >>>
> > >> --
> > >> what we call human nature is actually human habit
> > >> --
> > >> http://gleamynode.net/
> > >>
> > >
> > >
> > >
> >
> >
>
>
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
