Re: qualms about respond_to? idiom

On Fri, 15 Feb 2002, Gunnar Andersson wrote:

>
> > Hugh Sasse writes:
> > On Thu, 14 Feb 2002, Dave Thomas wrote:
>
> > > A polymorphic way of doing this is to move responsibility
> > > down to the
> > > stream elements. Say each had a method handle_stack. Then your main
> > > code could simply call handle_stack on _all_ tags:
> > >
> > >    e.handle_stack(context)
>
> > So is this an example of "Tell, Don't Ask", or is that more about an
> > object's internal state?  It does overcome this
> > problem, but it also means all the objects have to know how
> > to handle a
> > stack.  Doesn't that lead to "unnecessary" coupling between objects?
>
> Well you have type-dependent behavior so you really only have those
> choices, I'd say.
>
>  1. Either you switch on the type, which is what the original
>     was doing, basically.
>  2. Or you use the polymorphic approach and make use of dynamic
>     dispatch.

I think we are agreed that *in general*, 2 is preferable...
>
>  Looking at Dave's example, using names like "stack" and "push"
>  works because it is unlikely you'd want to handle your XML tags
>  in a queue.  It is clear a stack is the way to go and probably not
>  much to worry about.

I'm happy about there being a stack.  But there may be other things you
want to do with your XML tags which raise the same problem, as I'll
try to clarify below...
>
>  But in similar cases, if you don't want to pass out the stack,
>  there are other ways, like passing self, the tag calls back on
>  that,  and your tag-juggling-object delegates the "push" to the
>  internal stack.  (or "store" in the example below)

So it is sort of held within the object itself?

>  You've coupled the tags and their handler (this is inevitable),
>  but at least not thrown a Stack and it's specific push/pop methods
>  into the mix.

I think this is more what I am after. (Again, below...)
>
>  class Handler
>
>       ... foo-juggling-code ...
>       foo.maybe_store_yourself(self)
>       ...
>
>     # This is called back from the Foos
>     def store(item)
>        # The fact that we use a stack is encapsulated...
>        @stack.push(item)
>     end
>
>
> end
>
>    # One type does:
>    def maybe_store_yourself(handler)
>      handler.store(self)
>    end
>
>    # Another type does nothing
>    def maybe_store_yourself(handler)
>    end

I think this is even better than having the method in each object you
want to store.  This means that the coupling won't get many(stacks,
trees, something-D.Knuth-may-invent-next-week) to many(XML tags, AST's,
DOM ojects, etc), each side couples to the handler. A Mediator pattern.

I think this overcomes the problem I was seeing.  As the project grows,
amd more things have to use the Stack, and the Stack is not the only
thing handling the objects, then combinatorial explosion results.  In
such a case the design rules of "minimise coupling" apply.
>
> <philosophy rant>
> Adds coupling?  You can look at _any_ piece of code and
> find at least some dependencies.  You either add coupling or

Agreed, but I was trying to think of scaling it to more classes
that might need to use the stack.  Also, I was asking to try and
understand the issues, rather than say "this is wrong".  I was
fairly certain Dave Thomas would have an excellent reason for
b(reak|end)ing rules about minimising coupling, but I couldn't
deduce it.

        [...]
> without it?  Sometimes you (not *YOU* but all of us, well, maybe not
> the gurus but anyway... ;-) have a tendency to over-analyze these
> things because we look at our dogmatic rules and see that either
> way we seem to break at least one of them.  In my experience,

Yes, some of the rules pull in different directions -- creative tension,
etc.  This is what I wanted to explore.  Sometimes the fact that
"Either way you break a rule" means your looking at the problem
incorrectly, and you need to break an assumption, which is unstated.
Hence lateral thinking.

> after thinking "enough", you try one thing and if that doesn't
> really work in the long run, it will show (smell) and you
> refactor.
> </philosophy rant>
>
> So basically you have those two choices.
>
> Should you choose to switch on type, I would prefer doing it
> in a more explicit way.  respond_to? is most likely just a
> concealed way of switching on type, albeit somewhat more flexible
> than switching on the object's Class.
> In some cases (a limited use of) respond_to? makes sense, in
> others not.

Agreed. It would be nice if one could examine the contract of the
method, but until we have Design by Contract I won't open that can
of worms!
        [...]
> And consider the success of functional programming in some
> fields.  A lot of functions are polymorphic, but you also
> see quite some pattern-matching (=switch on type, more or less)
> to decide what to actually do.

This suggests to me that our language/thinking is geared so much
to physical things that we have difficulty in extracting a set of
behaviours as an abstraction to use in reasoning.
>
> What's one reason to love the Ruby community?  Because of the smart
> people in it!  Some of the discussions here are great!  I sure
> learn a lot.

Yes, me too.
>
> Cheers
> /Gunnar

        Hugh