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