View · Search · Index
No registered users in community xowiki
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

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik und Neue Medien
Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien