Jeremy White wrote:
My 2 cents.
SW_* constants are not defined in GUI_constants.cpp (nor exported in
GUI.pm). In general there are many constants missing.
Constant handling is, and will be a pain to get right.
See below.
Personally, I
don't like the way Win32::GUI exports all it's constants by default -
it's a huge waste of memory. I create separate packages for each window,
and I used to have "use Win32::GUI" at the top of each package to get
access to the constants. From memory, this added around 100K per package
where Win32::GUI was used. When using constants I now use the full name,
i.e., Win32::GUI::WS_CLIPCHILDREN.
I'm with you on this one. Glenn is correct that the way it is currently
done using AutoLoad saves on compile time, as the subs are only created
(eval'ed) on first use, however, he misses the point that every exported
variable creates an entry in the exporting namespace's stash. As you
say this is a huge waste of memory.
Using autoload to bring in the constants dynamically, is an alternative
solution but all the constant strings will have to be in the dll - and
if we're talking about adding *all* the constants, the dll could become
quite large...
And it's already too big! I am personally convinced that a separate
module is the way to go. I have not decided yet if a pure perl
implementation would do, or whether an XS implementation is necessary
for speed.
I'm not sure what the best solution is. Personally, I would prefer if no
more constants where exported as a default (unless they are commonly
used), but adding them to GUI_constants.cpp is fine by me.
I'd personally prefer neither at the moment (except, as you say, for
common ones).
I also like the idea of generating GUI_constants.cpp automatically from
(say) a flat file of constants - it would certainly make adding
constants easier! Even if we end up having thousands of autoloaded
constants, I don't think we would need to change the current algorithm
(even though it's far from optimal) as autoloader only needs to do the
look up once for each constant used.
I actually started looking at something like this a couple of weeks ago
when there were a large number of constants that I wanted to use that
were not available. I have some prototype code, but there are still
problems that I want to see if I can address:
Primarily I want constants to be inlined for speed. In order for this
to happen the subroutine must have been seen by the compiler before it
sees the constant in your code, so that it knows that it can be inlined;
however, if we are autoloading the subroutines, then they are not
compiled until the eval happens at run time - so they are not inlined.
A possible way around this is to not use Exporter, but to write our own
import() function that does the eval on the constants being exported -
the downside of this is compile time overhead for each exported
constant, regardless of whether it is used or not. Additionally, using
the constants as Win32::GUI::Constant::ES_WANTRETURN (i.e. not exporting
them) would never be inlined.
There are also differences between perl 5.6.1 and 5.8.x that I haven't
managed to work around yet.
It seems we can't have our case and eat it in this case. I will look
further into this at a future date.
Regards,
Rob.
