Imports in DWT

torhu no at spam.invalid
Tue Feb 26 14:41:40 PST 2008


Frank Benoit wrote:
> I wonder what is the best import strategy for DWT. Well, i know there is 
> no single "right way". So what are your thoughts?
> 
> 1. import everything explicitely
> 
> 2. have a dwt.all module that imports really all
> 
> 3. have groups import modules aka tango
> 
> 4. publically import all types used in the API of a widget.
>     So dwt.Button would publically import:
>      - dwt.DWT
>      - dwt.widget.Control
>      - dwt.widget.Composite
>      - dwt.events.SelectionListener
>      - dwt.graphics.Point
>      - dwt.graphics.Image
> 
> 
> 5. publically import API types, but only manually picked ones
>     dwt.layout.GridLayout:
>      - dwt.layout.GridData
>     dwt.Button:
>      - dwt.DWT
>      - dwt.events.SelectionListener

Personally I'm not very keen on importing more than I really need.  My 
app's already big enough.  So I guess I would prefer alternative 4 or 5, 
or just leave it the way it is.

The problem with using dwt.all is that if you use bud or rebuild, they 
can't see the difference between modules you import and use, and modules 
you import but don't use.  If you import a module, but don't use it, 
it'll still get compiled and linked.  So you're back to a more manual 
(makefiles, etc) build process if you want to avoid bloating your 
executable.

dwt.all is handy, but people should probably be aware the effect it has 
if they use it.

I tried building importing bobef's dwt.all into controlexample.d, and 
building it with bud.  The resultant exe was 3.0 MB.  Without dwt.all, 
it was 2.1 MB.  I got the same numbers for my own app, which is odd 
since it uses a lot less dwt modules than controlexample does.

Of course, not everyone cares whether their app is 2 or 3 MB.


More information about the Digitalmars-d-dwt mailing list