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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
