[fpc-devel] property syntax extension
marc at dommelstein.net
Sun Oct 21 22:25:23 CEST 2007
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);
>>> inherited ppuwrite(ppufile);
>>> 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?
> 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
More information about the fpc-devel