[fpc-devel] property syntax extension
Michael Van Canneyt
michael at freepascal.org
Thu Oct 18 13:53:57 CEST 2007
On Thu, 18 Oct 2007, Paul Ishenin wrote:
> Hello, fpc-developer list.
> Some time ago I posted here proposal to extend platform keyword. You gave a
> hostile reception to that proposal.
> Later Florian in private conversation with me suggested better idea of
> property attributes. Indeed, attributes are more general solution than
> platform keyword.
> Lets discuss this proposal.
> What is the purpose: extend rtti (or another structures that can be accessed
> at run time) with list of user defined Name=Value items.
> How it can be used: since it is generic solution different tools can use it in
> their own way. For example in LCL we can use attribute 'widgetset' to define
> widgetset specific properties and show such properties on another Tab of
> Object Inspector or with different colors (or show hints and so on).
I see no problem with this proposal from a language point of view.
The only problem is the storage. Your 'runtime access'.
I don't think it belongs in the RTTI. RTTI ends up in the binary, and
we get already enough complaints about binary size. A switch to leave
it out is not really a good solution, it shouldn't be in there in the
first place (apart from the technical feasability)
Also, the only place where this extended information is useful, is in
the Lazarus IDE (or any other IDE) Therefor I propose to simply write
it to the .ppu file, or - like the resource strings - to a separate file:
one per unit. (a .ppi file: "pascal property information").
Since the Lazarus IDE must one day learn to read .ppu files anyway, it seems more
logical to add the information there. You need the .ppu files in each case to
compile a binary, so storing it in the ppu makes sure it is available to the
IDE, but is not in the binary. Since you cannot have a working IDE without the
.ppu files of the RTL/FCL/LCL, you are guaranteed that the information is always
Now, if you want to have it in RTTI regardless of these arguments:
In that case I propose to reverse the switch you mentioned: People should
actually ask the compiler to have the extra property information included.
This way, normally only the lazarus IDE needs to be compiled with this switch.
It also makes sure the switch is implemented as part of the feature :-)
To achieve that, I think the extra RTTI will have to be written in tables
totally separate from the RTTI table (just like the message and resource
string tables). But that is a technical issue.
More information about the fpc-devel