[Dune] Returning Geometries As Objects

[Martin Nolte]

Hi Carsten,

you're right, I forgot the grid modification as a point where geometries could 
become invalid and I agree that this is a very good candidate. In the long 
run, I think this is a good solution.

However, I don't understand your suggested way of implementation: Do you want 
to merge now or implement the enhanced lifetime in the branch before merging? 
Or both, i.e., merge now and then implement the enhanced lifetime in the branch?

I also do not understand whether you want the implementation of the new policy 
to be a showstopper for the next release (d). If so, I fear there might be no 
2012 release.

With respect to a release before the merge (e), I agree (of course). However, 
I feel the way you describe with every release...

Best,

Martin

On 02/07/2012 01:45 PM, Carsten Gräser wrote:
> Am 07.02.2012 12:07, schrieb Martin Nolte:
>> Hi Oli,
>>
>> as far as I understood Christian, he wants the lifetime (I mean the time
>> in which the geometry remains valid) to be unlimited before the next
>> release. Changing the user code to call geometry only once (which would
>> be wise anyway) might take a lot of time and, therefore, I think a
>> longer transition period would be good.
>>
>> Moreover, I'm still not sure on the correct path. I see at least three
>> possibilities:
>>
>> A geometry object is valid
>> (a) for ever (i.e., as long as it exists)
>> (b) as long as the grid, the entity belongs to
> Do you mean: 'As long as the grid is not modified.' by this?
> Otherwise I suggest this as (b').
>
> Carsten
>
>
>> (c) as long as the entity exists within the grid
>> (d) as long as the corresponding entity pointer is valid (current
>> situation)
>>
>> I think we should at least prescribe (c), so that, e.g., references to
>> the corners are allowed.
>>
>> So: What kind of limit on the lifetime of a geometry do you have in mind?
>>
>> Best,
>>
>> Martin
>>
>>
>>
>> On 02/07/2012 11:56 AM, Oliver Sander wrote:
>>> This pretty much exactly reflects my view. I don't think I want the
>>> reference feature in there either. A variable that looks like an
>>> object but is in fact a reference is a big violation of the principle
>>> of least surprise. To me, the difficult-to-find bugs that lurk here
>>> are far more serious than potential speed loss.
>>>
>>> Concerning the speed loss: are the measurements of how much loss to
>>> expect? And can that not be mitigated in the calling code by making
>>> sure to call each geometry-Method only once?
>>>
>>> best,
>>> Oliver
>>>
>>>>
>>>> I'm against a merge, unless we agree to disable the reference feature
>>>> before the next release. Yes, this will require updates in all grid
>>>> implementations, but I think it is necessary to make this change show
>>>> its full potential and to actually value all the work and time you
>>>> spent here.
>>>>
>>>> If we can agree on this, I have no furthe objections regarding a
>>>> merge. I think it is well enough tested to actually do a merge. My
>>>> main concern is about adding undesired features which we (might) have
>>>> to deal with for an unforseable time.
>>>>
>>>> And "we agree" does not necessarily require a formal vote. I think it
>>>> just means that those people involved in (core) grid implementations
>>>> have to agree. I, for my part, am willing to do add the necessary
>>>> changes. Now we only need an opinion from Robert and Oliver [assuming
>>>> that you actually want to use you new feature ;-)].
>>>>
>>>> Cheers
>>>> Christian
>
> _______________________________________________
> 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