If the Win32::GUI::Constant package is a XS/C code we'll be able to come
up with various algorithms that compress the text strings meaning the
resulting dll could be relatively small.
But that imports the name into the current package, which is true namespace
clutter, and using bare-name constants from the current package don't
reflect the origin of the constant, and using the fully-qualified name
anyway to reflectt the origin of the constant is extremely long.
I think that's what Win32::GUI does now, it pollutes each name space if
Win32::GUI () is used - hence I was loosing around 100k per package.
So if all this could be achieved with Win32::GUI::Constant, why could it
not be achieved with Win32::GUI directly?
The advantage of having a separate package/dll is that if you dont want to
use it, you dont have to - this could become an important issue if the
constant code becomes large (especally if it's generated automatically via
the headers).
Importing exactly the constants used (per your first example) into the
local namespace would (I guess) allow the performance speedup of inlined
constants, which May may like.
I think so too - but I'm not 100% sure:)
Cheers,
jez.
