[Dune] [Dune-Commit] dune-localfunctions r943 - trunk/dune/localfunctions/test

[Martin Nolte]

Dear Jö,

as far as I know, the issue whether the implementation should be accessible was
discussed on the developer meeting and it was decided that additional
functionality should _not_ be accessible to the user. For testing purposes, a
special macro shall be defined to grant access to getRealImp().

While I did wish the getRealImp() method (my preferred name would have been
impl(), though) to be public, this is not going to happen. So we have to live
with this decision :-(. On the other hand, having the facade inbetween the user
and the implementation is a very useful safeguard. Moreover, this way you can
specialize for a Geometry or Entity in a generic way. Finally, the MockGeometry
is as useless as the Geometry and I think you yourself liked to have a simple
interface around the complicated BasicGeometry.

As for mydim, cdim and ctype, it is true that the implementation must know them.
But checking the interface is far easier, if they are specified as template
arguments and this tiny bit of redundancy does not harm in my opionion. It also
avoids problems due to incomplete templates.

Finally, I agree with Christian that it would be a good idea to introduce
additional namespaces. But this cannot be done before the release and, in my
opionion, should be done when adding the new module.

Best,

Martin


On 01/02/2011 04:11 PM, Jö Fahlke wrote:
> Am Sun,  2. Jan 2011, 11:58:15 +0100 schrieb Martin Nolte:
>> If we decide in favor of such a change (which will have to be voted on), we will
>> be forced to make the template argument GeometryImp a non-template. Otherwise,
>> the implementer cannot pass additional, grid-specific information to the
>> geometry implementation. The new declaration would look as follows:
>>
>> template< int mydim, int cdim, class ctype, class GeometryImp >
>> class Geometry;
> 
> I don't see why mydim, cdim, and ctype are needed as seperate template
> arguments; they must be known by GeometryImp anyway.  Why not just use
> 
>   template<class GeometryImp> class Geometry;
> 
>> Since we decided to move such geometry-specific stuff into a new module,
>> dune-geometry, a positive side effect is that the interface class Geometry could
>> then reside in dune-geometry instead of dune-grid. Of course, the latter change
>> will happen after the 2.0 release.
>>
>> What are the opinions of the other developers?
> 
> I don't really like the idea of wrapping some implementation just to enforce a
> particular interface.  The presence of certain functionality can be ensured by
> unit tests, and those can actually check that approximately the right thing
> happens.  The absence of additional functionality is not insured, since poeple
> will just use getRealImp(); is just makes the life of poeple who actually
> need[1] additional functionality harder.  The interface documentation is
> probably better done in a class GeometryInterface that exists just for
> documentation purposes.
> 
> So, in summary, I don't really see why we need Dune::Geometry in it's current
> form at all.
> 
> [1] And yes, "need" is not well-defined and tends to be subjective.
> 
> Happy new year,
> Jö.
> 

-- 
Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5642
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany