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: Sat, 18 Mar 2006 01:48:34 +0100
Scott Gargash schrieb:
> I've been thinking along somewhat different lines, the classic "extra
> level of indirection" that solves all problems. What about using
> interpreter aliases as an indirection? What would happen if all
> objects were created as anonymous commands inside (say) the xotcl
> namespace, and the object name was just an alias to the anonymous object?
>
you can do this easily by your own in xotcl. redefine e.g. unknown for
classes (or provide a mixin for create),
and create objects via new and add the alias.
====================================
Class instproc unknown {name args} {
set o [eval my new $args]
::interp alias {} $name {} $o
return $name
}
====================================
so, now we can test the aliased content. it behaves in many respects
the same, but when it comes to refer to "self" or to namespaces
one would notice a different behavior:
====================================
Class create Person -parameter {age}
Person p1 -age 123
puts [p1 age]
puts [p1 self]
====================================
As you noted, one can switch in such a universe the aliases
to "move" objects quickly.
====================================
Object instproc move {newname} {
foreach a [::interp aliases] {
if {[::interp alias {} $a] eq [self]} {set oldname $a;break}
}
::interp alias {} $newname {} [self]
::interp alias {} $oldname {}
}
p1 move p2
puts [p2 age]
puts [p2 self]
====================================
most probably, an associative array to keep the aliases is more
efficient than the loop through all aliases, once there are
many objects.
Note, that "self" remains the same.
If you need this kind of behavior for certain kind of objects, you
can certainly use a base-class RefObject or whatever, and subclass
the application classes from it.... This kind of objects will vertainly
need a destroy method to delete the alias as well.
-gustaf neumann
Date: Sat, 18 Mar 2006 01:48:34 +0100
Scott Gargash schrieb:
> I've been thinking along somewhat different lines, the classic "extra
> level of indirection" that solves all problems. What about using
> interpreter aliases as an indirection? What would happen if all
> objects were created as anonymous commands inside (say) the xotcl
> namespace, and the object name was just an alias to the anonymous object?
>
you can do this easily by your own in xotcl. redefine e.g. unknown for
classes (or provide a mixin for create),
and create objects via new and add the alias.
====================================
Class instproc unknown {name args} {
set o [eval my new $args]
::interp alias {} $name {} $o
return $name
}
====================================
so, now we can test the aliased content. it behaves in many respects
the same, but when it comes to refer to "self" or to namespaces
one would notice a different behavior:
====================================
Class create Person -parameter {age}
Person p1 -age 123
puts [p1 age]
puts [p1 self]
====================================
As you noted, one can switch in such a universe the aliases
to "move" objects quickly.
====================================
Object instproc move {newname} {
foreach a [::interp aliases] {
if {[::interp alias {} $a] eq [self]} {set oldname $a;break}
}
::interp alias {} $newname {} [self]
::interp alias {} $oldname {}
}
p1 move p2
puts [p2 age]
puts [p2 self]
====================================
most probably, an associative array to keep the aliases is more
efficient than the loop through all aliases, once there are
many objects.
Note, that "self" remains the same.
If you need this kind of behavior for certain kind of objects, you
can certainly use a base-class RefObject or whatever, and subclass
the application classes from it.... This kind of objects will vertainly
need a destroy method to delete the alias as well.
-gustaf neumann