paragui-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [paragui-users] Paragui redesign


From: Andrew Ford
Subject: Re: [paragui-users] Paragui redesign
Date: Mon, 6 May 2002 11:46:01 -0700 (PDT)

--- Alexander Pipelka <address@hidden> wrote:

> Right. The factory just has to create the objects.
> Parsing can also be
> added to PG_Widget.
> 
> 
> Is it a nessecity to declare constructors protected
> ?
> That would be a bit too much of abstraction for me.
> 

It isn't a necessity at all.  The problem is when you
mix ref-counting with the usual methods for creating
widets, local widgets and creation via new.  In this
case, the widget is actually owned by the user's
application and not paragui, but paragui still thinks
it owns the widget when we're ref-counting.  The user
can manage it (unless he screws it up and the system
blows up in his face).  He just has to make sure that
th object lasts as long as paragui is refering to it. 
When you use a factory to create all widgets (and not
just widgets parsed from the layout), you can "force"
the user to hold a reference to the widget, while
paragui has actual ownership of the thing.  We can
still make it so that the user isn't inconvenienced by
this decision, and the references automatically
dereference themselves with operator* and operator->
so that the user doesn't have to know anything about
the reference other than he gets a pointer-like thing
that he doesn't have to worry about deleting.  It's a
"this is for your own good, you'll thank me for this
when you're older" thing for the user.  The reference
class will also have a "get actual pointer"
(non-member) function so that the user can use an
actual pointer if he knows what he's doing and needs
it.

> Hmm,..
> One point seem curious to me with that refcounting.
> When do pointers get void (what would decrease the
> refcount) ?
> When deleting the pointer/object ?
>

When you're reference counting, basically every
reference is a small object that contains a pointer to
the object (widget in this case).  When it is copied
or to another reference, we now have two references,
so we increase the ref-count.  When one of these
objects are destroyed (either on the stack or
dynamically), we now have one less reference, so we
can decrement the ref-count.  Suppose the reference
count gets to zero.  In this case, nobody can access
the widget anymore so it can safely delete itself. 
Since we always know that our pointed object is always
a PG_Widget or derived, we're in good shape with this.
 Basically, the widget takes care of itself so that
the user doesn't have to worry about it.  As long as
he holds a reference, it's around, and as soon as he
(and paragui) doesn't, it goes away.  Something nasty
will almost certainly happen here if the user is
holding a dumb reference to the widget.  Of course, if
the user still wants to do this, perhaps we can
non-destructive references selectable via a policy
when the user instantiates the reference type for
paragui.  The user can decide he wants to be on his
own (if anyone is wondering why I keep using he/his,
we all know that girls can't program :) ).  We may be
able to set it up so that the user can command that
the widget be deleted right-now! invalidating any
references held to it (this would require specific
support both on the user and library side).
  Anyway, I'm rambling, but I think we can make
reference-counting at least as flexible as using local
widgets or pointers to widgets.
  I have a question for you.  What happens when we
declare a local widget and make it a child of another
widget, then the parent is deleted?  I ought to know
this, I know, but I've forgotten at the moment.

> >   Now that I'm thinking about it, isn't parsing
> the
> > XML attributes like sending events to the widgets,
> and
> > if treated like that, events not handled right now
> are
> > sent up to the super-class for handling until we
> get
> > to PG_Widget...
> 
> Kind of. But i think virtual functions fit perfectly
> for that.

So how do we pass specific attributes (or sets of
attributes that share some context) back to the
super-class for processing?  We obviously don't want
to do the full parsing in each widget (and users would
then hate laying out custom widgets).

Andrew.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]