$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-03-04 03:29:38
"David Turner" <dkturner_at_[hidden]> wrote in message
news:30013.165.165.239.17.1078386042.squirrel_at_webmail.telkomsa.net...
> Hi
>
> Thorsten wrote:
>
> > "David Turner" <dkturner_at_[hidden]> wrote in message
> > news:30053.165.165.239.17.1078382983.squirrel_at_webmail.telkomsa.net...
> > [snip]
> >> The only real problem with "why not" is that gui widgets have shallow
> >> copy
> >> semantics.
> >
> > And why is that a problem?
>
> Because it's surprising to the user (I think).
more surprising than hiding the type of window?
> More to the point, there is a very real problem with creating popup
> windows. Remember that the window acts as a factory for all other
> widgets, including popup (child) windows.
Hm...maybe I don't understand why it has to be that way?
> If I were to use the "why not"
> syntax, I would have to pass in the owner window as the first parameter of
> the constructor, as in:
>
> window w;
> button b(w, "Click here");
> w.contain(b);
why can't we say
window w;
w.add( button( "Click me" ) ); (*)
or
window.add( new button( "Click me" ) );
?
br
Thorsten
(*) I can imagine how this could work with a clonable class hierarchy. It
must be possible for an object to
register itself as a child of a parent window within the w.add() function.
That function could first create
a clone heap-allocated of the argument (to get polymorphism) and then add
that pointer to its list of children.