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). 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.
So as far as I'm concerned, this is more of a no-no.
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. 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?
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).
But this stuff REALLY has nothing to do with runtime...
Sergei
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
