<p>I don't understand why a property with a getter could ever be ran by a debugger.  If I have a property called NextValue, implanted by a method called GetNextValue, that increments a field, stores it in a database, and returns the new value, I absolutely do not want the debugger to execute that even if I'm dumb enough to try to ask it to view that property.  I would expect it to give me a rational error message such as "Property NextValue implemented by method GetNextValue" which would tell me that it understood what I was asking, and why it couldn't do it.</p>

<div class="gmail_quote">On Sep 12, 2011 4:14 PM, "Martin" <<a href="mailto:lazarus@mfriebe.de">lazarus@mfriebe.de</a>> wrote:<br type="attribution">> On 12/09/2011 20:46, Joost van der Sluis wrote:<br>
>> On Mon, 2011-09-12 at 20:31 +0200, Jonas Maebe wrote:<br>>>> On 12 Sep 2011, at 20:20, Martin wrote:<br>>>>>> Could not properties mapping to a function be implemented the same way =>  normal functions are already listed in "ptype" so<br>
>>>>>   public<br>>>>>>   property Counter: Integer read GetCounter<br>>>>>> could appear the same as the function "GetCounter" ?<br>>>>>><br>>>>>> In that case at least the list of available symbols is complete. The only thing that then would need codetools involved was to check if the name is a property and not a function/field.<br>
>>> That may be possible, yes.<br>>> What is it that we actually need? At the Dwarf-level:<br>>><br>>> Is the information that a property actually has a getter, and the name<br>>> of that getter enough?<br>
>><br>>> Or do we want that when the value of a property is asked, the getter is<br>>> called automagically? (And that there is some kind of flag that<br>>> indicates that a getter is being used?) I don't think that we can add a<br>
>> stack-script in the DW_AT_Location that executes the getter. I've looked<br>>> at DW_OP_call, but that won't help us here.<br>>><br>>> Or, and maybe this is the best solution: some 'opaque' type that returns<br>
>> a reference to something else. Which can be different for reading and<br>>> writing values...<br>>><br>> <br>> There are 2 conflicting desires.<br>> <br>> -data-evaluate-expression FooObject.BarObjProp.BarValue<br>
> ptype FooObject  / ptype FooObject.BarObjProp<br>> <br>> The first only works, ( at current) if it is a field, not a getter <br>> function. IMHO that is ok.<br>> <br>> While alot of people do want code execution for properties, there must <br>
> be a mean of control (in the front end, e.g lazarus). Even if that was <br>> enabled by default.<br>> That means, I would like that gdb does *not* automatically call the <br>> function.<br>> <br>> So for data evaluation we are fine.<br>
> If it is a function, the expression fails, and the IDE needs to look <br>> into it.<br>> <br>> Well having said that. If the function was only called, if brackets are <br>> supplied, maybe.....<br>> -data-evaluate-expression FooObject.BarObjProp().BarValue<br>
> <br>> But it is not a must. I am not even sure if desirable.<br>> <br>> --------<br>> the 2nd issue is knowledge that<br>> a) a there is something in the object under the name of the property<br>> b) this something happens to be a property<br>
> <br>> a) is already fulfilled if it is a field-property. Hence I asked, if <br>> functions could be added the same way.<br>> -data-evaluate-expression FooObject.GetCounter<br>> currently gets no value<br>
> -data-evaluate-expression FooObject.Counter<br>> gives an error, "no symbol"<br>> <br>> if Counter could be the same as GetCounter (making it effectively a <br>> function of the object), then at least the symbol was present.<br>
> And at the same time, this solves the question of "does it get executed <br>> or not" => same rules as for "GetCounter"<br>> <br>> b) The above of course does make no difference between it being a <br>
> property or just a function.<br>> <br>> for normal evaluation, this may most times make no difference. But for <br>> "debug inspector" type windows (that offer an object inspector like view <br>> of the object, with values) it may make a diff.<br>
> If the users setting is to auo-execute properties, then properties would <br>> be executed => but functions would not.<br>> <br>> So then it would be desirable, if there was any indicator between a <br>> function (or even field), and a property.<br>
> Ideally this difference would be viewable via gdb => but that is not <br>> even a must. Eventually the IDE will read dwarf directly, at which time <br>> it could make use of it.<br>> <br>> -------------------------<br>
> As for the whole "auto execution":<br>> <br>> I do not know what the options are => I have not even checked all the <br>> means of controlling it in gdb....<br>> <br>> <br>> ---------------------------<br>
> I know, that given that the IDE anyway hasn't support for it yet, it is <br>> a very early request.<br>> But support in the IDE is hard to implement, if the feature cannot be <br>> tested. And also given that it will take time until the feature is <br>
> present in a release, it is neer to early to ask....<br>> <br>> <br>> <br>> <br>> <br>> _______________________________________________<br>> fpc-devel maillist  -  <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br>
> <a href="http://lists.freepascal.org/mailman/listinfo/fpc-devel">http://lists.freepascal.org/mailman/listinfo/fpc-devel</a><br></div>