[Dune] Returning Geometries As Objects

[Carsten Gräser]

Hi Martin,

Am 07.02.2012 15:36, schrieb 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?
sorry if this was not clear: I'd like to first decide that we
want the extended lifetime. As soon as we did this: merge the branch
and then implement it in the trunk.

> 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.
Yes, I'min favor of making this a show stopper. The reason is simple:
IMHO its strange to force the user to modify the code to store
copies but at the same time saying that they don't behave like
copies yet---but they will soon.

Carsten

> 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

-- 
----------------------------------------------------------------------
Dr. Carsten Gräser       | phone: +49-30 / 838-75349
Freie Universität Berlin | fax  : +49-30 / 838-54977
Institut für Mathematik  | email: graeser at math.fu-berlin.de
Arnimallee 6             |
14195 Berlin, Germany    | URL  : http://page.mi.fu-berlin.de/graeser
----------------------------------------------------------------------