[fpc-devel] extending platform flag request

[Marc Weustink]

Some comments inline, imo, no need to comment on separate mails.

Sergei Gorelkin wrote:
> Tomas Hajny wrote:
>> �авоН ��онин wrote:
>>> Michael Van Canneyt wrote:
>>>> I think it's better to implement a string message dispatcher for this
>>>> instead of adding RTTI (which is already bulky as it is). 

This is optional. RTTI is info is already stored pretty compact. Only 
when specified this info can be added.

>>>> Do not forget
>>>> that the widget set is very lazarus specific, and has nothing to do 
>>>> with RTTI or even the OS/CPU platform that the compiler knows.

The example Paul gave is about widgetsets, but it could alse be use for 
indications of OS or CPU for instance.

When used for visual tools like lazarus, the RTTI is imo the only place 
to store this kind of info, but...
The platform directive is not bound to published properties only. That 
would mean that is has to be stored in the ppu somewhere.
(support for the platform directive has to be stored in the ppu anyway)
OTOH, you could say that this is an extention for published properties.

>>>> So as far as I'm concerned, this is more of a no-no.

What is the fun of the RTTI anyway ?

>>> We can add some hint ofcource like {%widgetset carbon qt}, write special
>>> parser for that, invent same as rtti structures to store string array of
>>> supported widgetsets. 

Besides, the parsing for this will become difficult when only compiled 
units are used.

>>> OR it can be easyly fited into existed platform
>>> keyword and without inventing second weel existed RTTI structure can be
>>> extented with arrat of string.
>>>
>>> If it is not lazarus but say component set developed for several
>>> platforms (libraries, os, whatever else) then platform string can be
>>> 'win32 linux osx' (if property is valid only for 3 os) or 'oracle
>>> interbase' (if property is valid only for 2 databases).
>>>
>>> Another advantage is that with extra info in platform keyword fpc will
>>> have more informative platform hints.
>>>
>>> I see no disadvantages.
>>
>> Where does the list of allowed values come from? How are the values
>> validated during compilation (what happens if someone types 'qr' instead
>> of 'qt' by mistake)? What would be the value of information stored this
>> way if there's no validation at all?

It is a kind of user feedback. And if someone had typed qr, then it will 
get noted that that property/routine is only valid for qr.
Its a hint, not something enforced by the compiler.

> The informativeness of 'platform' hints could be improved by including a 
> comment that is adjacent to the keyword, if one exists, e.g:
> 
> property SomeProp; platform; // qt and carbon only
> 
> Then hint will then be:
>  property 'SomeProp' is platform-specific (qt and carbon only).

Indeed, but then you have to scan comments. Which will be gone once you 
compile the unit.

> But this stuff REALLY has nothing to do with runtime...

The hints itself not. I agree.
But when doing RTTI, I might want to give the user some feedback.
In the current situation I've no option for that.

Marc