[fpc-devel] property syntax extension

[Michael Van Canneyt]

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 
present.

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.

Michael.