On 11/09/2011 22:36, Graeme Geldenhuys wrote:
On 11/09/2011, Jonas Maebe wrote:
Neither DWARF 3 nor DWARF 4 supports properties. I'm not aware of anyone
submitting a proposal to add them to the DWARF standard either. See e.g.
I was under the impression that you could now define (at least with
DWARF3 upwards) your own types or language constructs, without the
need for having those added to the official DWARF specifications.
That all fine and good, but all very long time.
I was more hoping, if there is any chance for a more "short" term
solution. (and maybe even including a work around in stabs)...
Like it was done for properties that directly map to a field. The now
are somehow encoded, so the field is read.
BTW anyone, why is that dwarf only => could stabs not just define
another entry under the property name?
Even then it would be a long way, because it would only be in fpc 2.6.2
(if merged) or 2.8.0; before a lazarus release would benefit.
On the other hand it would anyway take time for lazarus to be adapted to
use the info. And currently the info would have to be readable through
gdb, something I hope to change in future.
More than that, Lazarus is not the only way to use the info, people use
other IDEs or gdb directly => all that needs to be considered.
Also there are (at least to me) 2 levels.
1) Make available the info that a property exists, even if no way exists
to access it. (via gdb)
2) access to the data, or information about hpw to access (pointer to
getter/setter functions) (via gdb)
The first would simply mean that something in the "ptype" result of a
class indicates the presence of a property
Of course, if the property already maps (aliases) the field (if directly
mapped to field) then it is impossible for ptype to return a different
result, than the type of the field.
And returning the content of the field is essential, especially if
fields themself are structured types (classes).
FooObject.BarObjFieldProperty.BarValue
only works with the current "alias" solution.
While an IDE could transform the expression, if really that was needed,
a user using gdb directly would relay on this working (and for an IDE it
is much easier and leads to better performance, if that is working)
That already defies the idea of encoding properties as structure
(actually differnet properties = diff structures) with a field for
getter and setter.
The structure could have been identified as property by a none pascal
name (like the $fp framepointer in nested functions)
The structure approach would have been nice, as it would have provided
the info about the property in place of the real property name.
- It would have been fine if FooObject.BarObjFieldProperty would
return and display the whole structure. An IDE can deal with it, and a
gdb user can still read it (assuming that the structure displays all
it's values, rather than just an address)
- But it would break FooObject.BarObjFieldProperty.BarValue . Unless
the "." after the property can be tought to be an operator that uses the
"read-value" field (if it is a field)
(and similar for arras with [])
I am not sure if something like this can be done (and reliable with
current gdb versions)
---
Another approach, by far not as nice:
- Leave the getter as is / maybe add getters with function to declare
the property to be the same as the read function.
- And add another field PropertyName$Set with the setter info
Accessing a property in value evaluation would work as it does now.
An IDE getting a "ptype" could detect the xxx$Set entries, match the
getters, and know what is a property => even have a way of modifying
them, if it can do code-execution for that purpose...
Alternative xxx$Property with a record (or xxx$Set / xxx$get), to
provide info about properties; but leave the actual name mapped to the
field (were appropriate) so the expression evaluation would still work
Martin
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
