View · Search · Index
No registered users in community xowiki
in last 10 minutes

XOTcl/NX mailing list by object move?

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Thu, 16 Mar 2006 05:15:32 -0700

xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/15/2006 04:23:28 AM:

>
> On 15 Mar 2006, at 12:17, Gustaf Neumann wrote:
> >
>
> I am actually quite surprised to find that the move operation calls
> the destructor. This is not mentioned on the reference manual and
> does, in fact, seem counter-intuitive. A move is a move, nothing is
> being destroyed, so why call the destructor?

I agree. A move operation didn't imply object destruction to me, either.

> I understand that the
> operation is actually quite expensive, due to current Tcl internals,
> but is there any reason why a destructor should be called? If we want
> a method called for a move operation, surely it would be simple to
> define that a "beingMoved" method is then called.

I'm guessing that xotcl::object's "destroy" method does all the heavy lifting (cleaning up the
source of the move). What would happen if the default move implementation was to change the source
object's class to xotcl::object before invoking destroy? This way it would continue to use the
xotcl::object's "destroy" implementation for cleanup purposes without invoking all of the subclass
destroy methods, and derived classes wouldn't perceive move as a destroy operation. Would this have
bad side-effects?

> > it is quite simple
> > for a poweruser of xotcl to overload copy/move and add applicaton
> > specific addtional behavior to it. if one does not like the side-
> > effects
> > of destroy in a move, a custom move operation can set in instance
> > variable "__during_move__" and query this from the destroy
> > method to change its behavior.

While I'm no poweruser, I did get the guard mechanism to work. Here it is for completeness sake.
(Is there an easy way to search the mail archives? Maybe this will help someone else...)

# move doesn't do what I expect. It's not simply a move, it's
# actually a deep copy followed by a destroy. I want to reclaim the
# object on destroy, but not the imputed destroy from the move
# operation. So flag that the destroy is happening because of a move
# so the destroy reclamation doesn't happen, and then reset the flag
# in the new copy.
TrackingMixin instproc move {dest} {
  my set _ismoving_ 1
  next
  $dest unset _ismoving_
}
TrackingMixin instproc destroy {args} {
  if {[my info vars _ismoving_] eq ""} {
    # true destroy, do true destroy things...
  } else {
    next
  }
}


      Scott