No registered users in community xowiki
in last 10 minutes
in last 10 minutes
XOTcl/NX mailing list by object move?
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 17 Mar 2006 15:52:02 +0100
Scott Gargash schrieb:
> 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 would not expect this either, but it seems as a reasonable compomise.
It has been
like this since implemented more than five years ago and has not caused
any trouble.
maybe, it would have been better to provide only a copy operation, and
delay move,
until it can be made properly in c with a namespace rename operations.
anyhow,
for now, i have documented the copy+destroy operation in the manual.
>
> 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?
>
for some applications, it might be the right things, for others not.
>
> 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...)
>
This qualifies you at least as a candidate for a power user :).
you might place this on the tcl wiki (http://mini.net/tcl/XOTcl)
mailman has no nice search interface, maybe we will switch at some time
to something better....
best regards
-gustaf neumann
Date: Fri, 17 Mar 2006 15:52:02 +0100
Scott Gargash schrieb:
> 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 would not expect this either, but it seems as a reasonable compomise.
It has been
like this since implemented more than five years ago and has not caused
any trouble.
maybe, it would have been better to provide only a copy operation, and
delay move,
until it can be made properly in c with a namespace rename operations.
anyhow,
for now, i have documented the copy+destroy operation in the manual.
>
> 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?
>
for some applications, it might be the right things, for others not.
>
> 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...)
>
This qualifies you at least as a candidate for a power user :).
you might place this on the tcl wiki (http://mini.net/tcl/XOTcl)
mailman has no nice search interface, maybe we will switch at some time
to something better....
best regards
-gustaf neumann