Hi!
XOTclIDE does not run with XOTclI 1.3.1 because of uncompatibility of the namespace handling. Thank to Michael Heca for noting it.
I have played a little with xotcl and discovered following behavior incompatibility that make problems by XOTclIDE.
Examples:
package require XOTcl namespace import xotcl::*
Object O Class O::B O::B instproc test {} { Class A } O::B create o o test
# XOTcl 1.2 returns ::A # XOTcl 1.3 returns ::O::A
using Class ::A solves the problem
Another one should not occours by any XOTcl programm but by XOTclIDE this happened
Object O Class O::A O::A proc test {} { A self } O::A create A O::A test
# XOTcl 1.2 returns ::A # XOTcl 1.3 returns ::O::A # using ::A solves the problem
So probably even with XOTcl 1.3.2 XOTclIDE will not work out of the box and need some changes. So all XOTclIDE user be patience and wait for new version of XOTclIDE that supports XOTcl 1.3. I will need also some time to support new XOTcl functionality.
Artur Trzewik
Hi Artur,
it seems there are some flaws in the new namespace handling code that we did not foresee. In the first example, for instance, the current namespace "::O" is not correctly set, IMHO. I suggest: don't change your code now, but wait for the next release, because we need to fix this behavior first. After a quick assessment, I think either some larger changes to this are necessary or we remove the new namespace handling in the next release again. Here is a version of XOTcl with the namespace handling code disabled:
http://wi.wu-wien.ac.at/~uzdun/resources/xotcl-1.3.1.tar.gz
can you please verify that this version works as intended for you?
I then also produce windows binaries for this version ans likely put it on the web.
Uwe
Artur Trzewik wrote:
Hi!
XOTclIDE does not run with XOTclI 1.3.1 because of uncompatibility of the namespace handling. Thank to Michael Heca for noting it.
I have played a little with xotcl and discovered following behavior incompatibility that make problems by XOTclIDE.
Examples:
package require XOTcl namespace import xotcl::*
Object O Class O::B O::B instproc test {} { Class A } O::B create o o test
# XOTcl 1.2 returns ::A # XOTcl 1.3 returns ::O::A
using Class ::A solves the problem
Another one should not occours by any XOTcl programm but by XOTclIDE this happened
Object O Class O::A O::A proc test {} { A self } O::A create A O::A test
# XOTcl 1.2 returns ::A # XOTcl 1.3 returns ::O::A # using ::A solves the problem
So probably even with XOTcl 1.3.2 XOTclIDE will not work out of the box and need some changes. So all XOTclIDE user be patience and wait for new version of XOTclIDE that supports XOTcl 1.3. I will need also some time to support new XOTcl functionality.
Artur Trzewik
Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
On Thursday 02 September 2004 20:27, Artur Trzewik wrote:
Hi!
XOTclIDE does not run with XOTclI 1.3.1 because of uncompatibility of the namespace handling. Thank to Michael Heca for noting it.
The described problems all stem from cases where, objects are created in implicit namespaces. If the namespace is specified, they will disappear. While i see the example from Michael as a bug, i do not regard the examples below as such.
between 1.2 and 1.3, there was a big - but i think important - change in the handling of namespaces in xotcl. while most of the programs are not affected (no change in my codebase of more than 25000 lines of xotcl code), some programs are. I still believe that the 1.3 behavior is much better, since it allows to use xotcl in packages without - without having the need to import xotcl globally, - or to write all xotcl commands with the xotcl prefix (such as ::xotcl::self) in the package implementation, as it was requited in 1.2 and earlier. Furthermore, the new version is more compliant to the tcl behavior.
Look at the following example. Assume, you want to define a component test, that is defined in the "::test" namespace. Later, you want to use the component test and import from the test namespace, whatever you need. Whether or not the component test uses other components (such as xotcl) should not affect you.
In other words, a programmer should not be required to import xotcl globally, only because he is using a component that uses xotcl.
with 1.3, one can define the component
================================== namespace eval test { package require XOTcl namespace import ::xotcl::* Class C C set i 0 C proc new {} { [self] create c[my incr i] foreach i [[self] info instances] {puts -nonewline "$i "} puts "" } C instproc m {} { puts "[self]->[self proc] NS=[namespace current]" } namespace export C } ==================================
and use it later with
================================== namespace import test::* C new C new C new test::c1 m ==================================
differently to 1.2, we have now: - no globally imported xotcl commands - we can write xotcl code in a human friendly way (not prefixes) - the default namespace of the method m is "::test" (like in a tcl proc) - this default namespace is used when procs (or objects) are created
therefore, the objects created by new are now in the namespace, in which the creating command was defined, namely "test".
In the example below, subobjects are used. Since subobjects create their namespaces, the objects are created (and resolved) in these namespaces, similar as explained above.
If one wants explitly a different namespace, it should be specified explicitely. Michael's example
NS::Main proc m2 {} { namespace eval :: Object crash}
can be simpler defined as
NS::Main proc m2 {} { Object ::crash}
which will work. Nevertheless, as i wrote above, the example above should not crash and must be fixed.
If you have arguments against this change, or different proposals to get a similar behavior, please let me know.
It should not be a big problem to make XOTclIDE work with the old and new behavior. as always, we are willing to help.....
all the best
-gustaf
I have played a little with xotcl and discovered following behavior incompatibility that make problems by XOTclIDE.
Examples:
package require XOTcl namespace import xotcl::*
Object O Class O::B O::B instproc test {} { Class A } O::B create o o test
# XOTcl 1.2 returns ::A # XOTcl 1.3 returns ::O::A
using Class ::A solves the problem
Another one should not occours by any XOTcl programm but by XOTclIDE this happened
Object O Class O::A O::A proc test {} { A self } O::A create A O::A test
# XOTcl 1.2 returns ::A # XOTcl 1.3 returns ::O::A # using ::A solves the problem
So probably even with XOTcl 1.3.2 XOTclIDE will not work out of the box and need some changes. So all XOTclIDE user be patience and wait for new version of XOTclIDE that supports XOTcl 1.3. I will need also some time to support new XOTcl functionality.
Artur Trzewik
Xotcl mailing list - Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl