Glenn Linderman wrote:
from the keyboard of Robert May:
Glenn Linderman:
Robert May:
Glenn Linderman wrote:
My intention is:
- Win32::GUI::Constants will export nothing by default.
- there will be a tag for the current set of symbols. Any suggestions
for a name?
:compatibility_set
I've gone for :compatibility_win32_gui
- When we move Win32::GUI to use this, for the first release it will
continue to export the current set of symbols, but will raise a
'deprecated' warning. Future releases will export nothing. Release
notes will document the changes.
OK, but for Jez (and for migration/planning) we should add an option
that allows one to turn off the export of the current set of symbols, in
the first release of GUI that uses Constants.
use Win32::GUI ();
will not export anything, as you'd expect, and as happens today. I
think this is what Jez is already doing.
(4) What other groups of constants should we have?
I think there is a need for some tags, as it's not always possible to
do simple regexs for all the constants related to a topic. For
example all toolbar related constants requires:
^BTNS_
^TBSTATE_
^TBSTYLE_
^I_
Right, so that's an appropriate grouping. Your example leads to the
following idea: maybe each Win32::GUI::widget class should be examined
for the sets of constants that are relevant to the widget, and if there
is more than a single pattern required to get the set of constants, then
a tag with the widget name could be created.
Even if there is only a single pattern (which I suspect is unlikely,
given messages, styles, notifications etc.) then I think that we should
have a :tag for each class to make life easy for quick prototyping. Of
course, production code will probably want the constants listed
explicitly, so that Tags.pm is not loaded, and for minimal overhead.
By defining %TAG_SPECS to be a hash of a list of patterns, you've kept
the definition size to a minimum, and the full list of names is only
generated if the tag is used. This is clever. So clever that I'm not
sure it needed to be an extra module, in the end, but having it is not a
problem either.
Where there are patterns it works really well, but there are some tags
that are not going to be small like this. For example
:compatibility_win32_gui is 350 odd constants, and must be an exact
match, even if more constants get added to this module in the future, as
otherwise we'll start invoking re-definition errors on people's code
where they have a 'sub' or 'use constants' definition for something that
wasn't there before. Also the 'stock objects' for GetStockObject()
can't be matched by a nice pattern.
And it is clever enough that I won't suggest folding the code that is in
Tags.pm back into Constants.pm and having a separate module for each
individual tag, so that only the tag lists that are actually used need
to be loaded, because the patterns, and even sets of patterns, are
extremely small.
Additional modules for each (or some of) the tags may be something to
consider, once we see how big Tags.pm gets.
Tags.pm line 24: "use use" should be "for use"
Constants.pm line 91: "implemenation" is missing a "t"
Constants.ps line 107: "pargmata" should be "pragmata"
Constants.ps line 131: "like" should be "likely"
Constants.ps line 198: "and" should be "an"
Thanks, got that.
I'll work on a few more tags, then up the version to 0.01, and release
it as experimental from my site. I'll try to fold it into Win32::GUI
1.04, assuming that I'll get 1.03 out soon.
Regards,
Rob.
