No registered users in community xowiki
in last 10 minutes
in last 10 minutes
XOTcl/NX mailing list by XOTcl 1.3.1 (XOTclIDE)
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 14 Sep 2004 16:29:47 +0200
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_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
Date: Tue, 14 Sep 2004 16:29:47 +0200
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_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
-- Univ.Prof. Dr.Gustaf Neumann Abteilung für Wirtschaftsinformatik und Neue Medien Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien