[petsc-dev] We need to cleanup viewers

[Barry Smith]

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

> Barry Smith <bsmith at mcs.anl.gov> writes:
>>>    I cannot think of a reason not to throw an error for unrecognized viewers.
>> 
>>   That was the old model and it was terrible. Thus we changed to silently ignore unrecognized viewers.
> 
> How is this not confusing to users?  If they explicitly call XXView(x,v)
> and it does nothing, how do they figure out what is wrong?  Maybe
> viewers could have an option marking them as optional?

   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.

> 
>>> 2) We need to rationalize behavior with conditionally compiled viewers
>>> 
>>>    Jed proposes a registration process.
>> 
>>    Finally a real system for double dispatch?
> 
> I hate the fact that Viewers are not really extensible.  We have a hacky
> sort of multiple dispatch in Mat, but we could do it right and improve
> Mat performance while we're at it.  Fast implementations in the CL world
> are as old as I am, which brings us to
> 
> https://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule

   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.

   Barry

> 
>>> A simpler, but uglier solution is to
>>>    protect the dispatch call and speciailzed view function with #ifdef and
>>>    provide an error at the dispatch point.
>> 
>>  How are we not doing this now?
> 
> There are places in the code where #ifdef is used at a higher level,
> creating lots of clutter.