[petsc-dev] We need to cleanup viewers

[Barry Smith]

On Mar 27, 2014, at 11:51 AM, Jed Brown <jed at jedbrown.org> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
>>   The problem is that many viewers call viewers on inner objects
>>   recursively. Under the old system if ANY of the inner objects, no
>>   matter how freaking trivial did not support the users viewer BOOM
>>   end of program with error message. Very annoying. For all objects
>>   writing “empty” routines that just return for each and every
>>   possible viewers is impossible and never kept up to date. Hence the
>>   current model which is not confusing at all if users understand
>>   that not all objects respond to all viewers.
> 
> In those cases, could the top level flag those viewers as optional
> before passing it down to lower levels?

   Maybe, but it seems like an unneeded complication to the code. Each individual complication may seem reasonable at the time but once they pile up you get Trilinos crap.

   And how does each “higher level” object decide which ones below are optional or not optional since that may depend on context.

   My take: I found the old way of requiring some code for each object or generating an error as very anouying and painful, code was constantly stopping in the middle due to some trivial “missing” viewer that won’t do anything important anyways. Once I stripped out all the error generation I was much happier and never had an issue at all. I’m guessing that you and Matt got all hung up about this recently because some moronic user didn’t get some output for some viewer and had a melt-down/panic attack and turned off their brain. I am not yet convinced that there is a problem that actually needs to be solved.

   Barry





> 
>>   I would be very happy to see the viewers handled properly with a
>>   double dispatch system. But that system needs to be designed and
>>   evaluated. I wrote this sentence because I would be very happy if
>>   you wrote a proper double dispatch system for viewers that passes
>>   our satisfactory requirements. I just don’t want a half-assed
>>   crappy confusing 1 1/2 dispatch system that sucks.
> 
> I'll experiment with this after the release.