[Dune] [Dune-Commit] dune-grid r7996 - trunk/dune/grid/common
Martin Nolte
nolte at mathematik.uni-freiburg.de
Wed Apr 18 14:56:27 CEST 2012
Hi Oli,
actually I was a little surprised when you marked the boundaryId deprecated
without a fully implemented alternative (actually, I undeprecated it locally a
few seconds later). I thought the agreement was to mark the boundaryId
deprecated once the alternative is fully implemented.
Anyway, in my opinion the solution is suboptimal, because it will remove the
method from the next release unless experimental grid extensions are switched
on without a working replacement. And, as Christian pointed out, the
boundaryId is not an experimental grid extension which can only be accessed
through the implementation of the grid objects but is part of the current
interface.
(a) wait until the replacement is fully implemented (i.e., undeprecate the
method again),
(b) fully implement the replacement _before_ the next release,
(c) write a utility class (specialized over the grids) that provides the
boundaryId (and that is not going to be removed at all).
Approach (c) reflects the fact that the boundaryId will probably never be
removed from AlbertaGrid and ALUGrid, so there might as well be some structure
to obtain it.
Personally, I would favor (a), because I do think the boundarySegmentIndex
stuff still needs further discussion and the problems in parallel will
probably not be resolved before the next developer meeting (which is going to
be after the release?). In my opinion, we should not remove features from the
interface without a proper (read: implemented and tested) alternative.
Best,
Martin
On 04/18/2012 01:57 PM, Oliver Sander wrote:
> Hi Christian,
> don't yell at Robert, this was actually my idea. Rationale: We agreed
> to have this feature removed. However so far there is no good alternative
> that works in parallel. This is my personal fault: at the last meeting
> I volunteered to come up with an alternative, but I never did.
> Robert was annoyed by the warnings, but I wanted to keep them in.
> As a compromise we settled on what Robert just committed. I don't
> think many people use the experimental features (and if they do they
> do it on their own risk). Hence most people will still see the warning.
>
> best,
> Oliver
>
> Am 18.04.2012 13:44, schrieb Christian Engwer:
>> Hi Robert,
>>
>>> Log:
>>> allow normal use of boundaryId when experimental extensions are enabled.
>>
>> Could you please explain why this is the intended behavior? As far as
>> I recall we decided to remove the boundaryId, meaning that it is not
>> an experimental feature, but will be removed. I still think people
>> would like to be warned about this future removal, even if they use
>> experimental features. If you disagree, I'd consider a change in the
>> semantics of DUNE_DEPRECATE the appropriate fix, because other
>> deprecation warnings are still on, although experimental extensions
>> are activated.
>>
>> Christian
>>
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
--
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>
Universität Freiburg phone: +49-761-203-5630
Abteilung für angewandte Mathematik fax: +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany
More information about the Dune
mailing list