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

[Jö Fahlke]

Am Sun,  2. Jan 2011, 17:01:46 +0100 schrieb Martin Nolte:
> 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 :-(.

Don't get me wrong, I do think having non-interface functionality on something
like the Geometry is a bad idea.  But I also think that inhibiting it using
this facade wrapper as we do it currently is going a bit too far.

>                         On the other hand, having the facade inbetween the user
> and the implementation is a very useful safeguard.

Against what are we safeguarding here exactly?  I always thought we wanted to
ensure that a certain interface exists, but consider for instance the
following code

======================================================================
struct Engine {
  void foo() { std::cout << "Engine::foo()" << std::endl; }
};

template<class Engine>
class Facade {
  Engine engine;

public:
  void foo() { engine.foo(); }
  void bar() { engine.bar(); }
};

int main() {
  Facade<Engine> facade;
  facade.foo();
};
======================================================================

This will compile without problem, even though it looks like Facade::bar() is
expecting a method Engine::bar(), which does not exist.

>                                                    Moreover, this way you can
> specialize for a Geometry or Entity in a generic way.

Depends what you want to specialize for.  You can specialize for mydim, cdim
or ctype using enable_if even without the Dune::Geometry template.  But you
are right in so far as it is probably easier if the parameter you want to
specialize for is a template parameter of Dune::Geometry (which is not the
case for ctype currently).

Specializing for GeometryImp is either easy or impossible both with or without
Dune::Geometry -- it is impossible if the GeometryImp template is a member of
some other template class.

>                                                       Finally, the MockGeometry
> is as useless as the Geometry and I think you yourself liked to have a simple
> interface around the complicated BasicGeometry.

Actually, I wanted to have some class that provides the same interface as a
Dune::Geometry (after construction), so I could use it as a drop-in
replacement.  Since BasicGeometry has different member types and the Jacobian
types are not field matrices, I cannot use it directly.  I will happily use a
Dune::Geometry once it no longer requires a Grid.  But I don't see

> 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.

I looked at the code and I do not understand how it would get more complicated
without the template arguments for mydim and cdim, once GeometryImp is changed
from a template to a type.  In dune/grid/common/geometry.hh you simply extract
mydim, cdim and ctype from GeometryImp instead of using the template
arguments.  In dune/grid/test/checkgeometry.cc it is basically the same.  Did
I miss any check?

Could you please elaborate on "problems due to incomplete templates"?  You
have lost me here...

> 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.

Agreed.

Bye,
Jö.

-- 
This just in: "Since 2001, there has been a 300-fold rise in terror
acts worldwide".  Know what would be cool?  If the Bush administration
declared a war on jobs.
-- J.L. Grant, http://flem.comicgenesis.com/d/20040726.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20110103/217c3cd4/attachment.sig>