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