[fpc-devel] property syntax extension

[Marc Weustink]

Florian Klaempfl wrote:
> Mattias Gaertner schrieb:
>> On Sun, 21 Oct 2007 08:36:24 +0200 (CEST)
>> Daniël Mantione <daniel.mantione at freepascal.org> wrote:
>>
>>> Op Sun, 21 Oct 2007, schreef Michael Van Canneyt:
>>>
>>>>>> .ppu file format is something so general and 
>>>>>> commonly used by (Free) Pascal programmers that 
>>>>>> it should become part of our RTL.
>>>>> And another:
>>>>> A lazarus built with fpc 2.0.4 should be able to read the ppu of
>>>>> 2.3.x. Even though the ppu format is very stable, it is not
>>>>> carved in stone.
>>>> It's built so that a newer version can always read an older PPU file
>>>> and vice versa: an old ppu unit can read a newer file, but just
>>>> doesn't know how to interpret certain blocks.
>>> This is not true. Take for example:
>>>
>>>     procedure tarraydef.ppuwrite(ppufile:tcompilerppufile);
>>>       begin
>>>          inherited ppuwrite(ppufile);
>>>          ppufile.putderef(_elementdefderef);
>>>          ppufile.putderef(rangedefderef);
>>>          ppufile.putaint(lowrange);
>>>          ppufile.putaint(highrange);
>>>          ppufile.putsmallset(arrayoptions);
>>>          ppufile.writeentry(ibarraydef);
>>>       end;
>>>
>>> If the arrayoptions for example becomes a large set (>32 elements), an
>>> old version that will try to read a new version will read too little 
>>> data. We will of course bump the ppu version, so the compile refuses
>>> old ppus. 
>> Is the newer ppureader be able to read older ppu?
>> In other words: Does a current ppureader contains the code to read the
>> old format too?
> 
> No.
> 
> I discussed this already with Paul. My proposal is generate a separate
> xml file containing the attributes. This xml can be used by IDEs or
> included in the final executable if necessary.

I discussed with Paul to and I'm not really pro reading and parsing yet 
another file. Since I think attibutes are valid for more than only 
published properties/methods putting them in RTTi would be to limited. 
Besides that, as already stated, it's not really necesary to put this 
info in the final executable.
Therefore I suggested to put the info in the ppu, something what popped 
up in a previous discussion. IMO, lazarus will be capabable of reading 
ppus someday to get rid of the requirement that you can only have 
autocompletion etc. when all the sources are readable and parsable.

 From the current discussion I realize that different versions of ppu 
files need to be parsed, current formats and future formats. The latter 
case will bring some difficulties.

With this in mind, I think indeed that a compiler generated second file 
with xml info about the unit is a better solution. Given that all the 
info a 3rd party like lazarus would read from source or ppu would be 
available in that info file. This way all info is quickly available by 
one file.

Marc