Weblog Page

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Thu, 8 Sep 2005 16:04:54 +0300 (EEST)

On Thu, 8 Sep 2005, Neil Madden wrote:

> Kristoffer Lawson wrote:
>>
>> That is two fine. I would prefer to have lots of related classes being part
>> of the same Tcl package. For that, I have to build a stub package which
>> then includes the rest in the appropriate order (or using some kind of
>> sub-packaging).
>
> You should be able to handle this with a custom pkgIndex.tcl file. I would
> personally opt for the fine-grained packaging mechanism though, for more
> flexibility.

Yeah, a custom pkgIndex would be a good idea too. I'm not a big fan of the
fine-grained mechanism myself. I prefer to just say 'I want this package
and all the classes that go with it', instead of listening all the classes
I will happen to need. I know some people do that in Java too, but I just
find it grows into a long mess with time.

                               / http://www.fishpool.com/~setok/

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 29 Nov 2011 09:21:10 +0100

Dear Arthur,

The short answer is: object parameter are the preferred way,
these fit better to dynamic languages and avoid several
potential anomalies (see e.g. the example from the slides of
the 2011 Tcl conference)

The longer answer (not necessarily introductory): For NX the
object parameters are the only way, but the object
parameters can be positional and/or non-positional, as for
parameter definitions for methods. The object signature is
derived from the slots of the class hierarchy from which an
object is instantiated. The derived signature is a sequence
of positional and non-positional parameter specs. For object
parameters, typically most parameter specs are
non-positional, just the last spec is positional (the init
script). Certainly, this can be extended:

Here is a short example.

    nx::Class create C { :property x }
    nx::Class create D -superclass C { :property y }
    D create d1 -y 123

This script implies an object signature for D of the form
"-x -y .... {init-script}" (simplified).
If one adds a positional parameter

    nx::Class create E -superclass D { :property {z ""} {set :positional 1} }

the signature of E becomes "z -x -y ... {init-script}" (also
simplified).
With this signature, one can create objects e.g. via

    E create e1 "hello world"

For the positional parameters, a position can be added (the
non-pos paramters start at position 1, so use e.g. 0.1, 0.2
etc.). However, for beginners i would recommend to stick to
the default behavior with just non-positional object
parameters...

best regards
Gustaf Neumann

PS: XOTcl (and XOTcl 2) support method parameters for
constructors, and since XOTcl 2 and NX are based on nsf,
this could be done as well in NX (somewhat contradictory to
above, but such a modification would require low-level
modifications to NX, it would not be the same NX). However,
when method parameters to constructors should be as well
positional and non-positional, these tend to become a source
for confusion, at least, if one wants to support derived
object-parameters....

On 28.11.11 21:53, Arthur Schreiber wrote:
> Hello everyone,
>
> Is there any way to pass arguments to the init method in NX (as in XOTcl)?
> Or is using object parameters on initialization the preferred way in NX
> to initialize an objects instance variables?
>
> Thanks,
> Arthur
>

From: Victor Mayevski <vitick_at_gmail.com>
Date: Wed, 29 Sep 2010 10:58:55 -0700 (PDT)

Thank you Gustaf,

Part of my original question, which still stands, was "would it be worth it?"

It seems that the example you provided can be done with XOTcl alone, no need for coroutine. Is there any case where coroutine would actually give some extra power to XOTcl? Forgive me, I am not a C programmer so the concept of NRE or stackless TCL is a little foggy to me.



----- Original Message -----
From: "Gustaf Neumann" <neumann_at_wu-wien.ac.at>
To: xotcl_at_alice.wu-wien.ac.at
Sent: Tuesday, September 28, 2010 2:49:06 AM GMT -08:00 US/Canada Pacific
Subject: Re: [Xotcl] coroutines

  On 02.09.10 07:28, Victor Mayevski wrote:
> I am wondering if it will be possible to somehow implement coroutines in XOTcl? Is it feasible? Would it be worth it?
Sorry for the late answer. With XOTcl 1.6.* there is no
special support
for coroutines (one can certainly create Tcl-coroutines and
use it).

With 2.0 one can write object oriented coroutines.
The new regression test contains already the classical
number generator
example based on coroutines (see below).

-gustaf neumann

=========================================================
Test case number-generator {

   Object create numbers {

     # set instance variable used in coroutine
     set :delta 2

     :public method ++ {} {
       yield
       set i 0
       while 1 {
         yield $i
         incr i ${:delta}
       }
     }
   }

   # create coroutine
   coroutine nextNumber numbers ++
   set ::j 0

   # use coroutine
   for {set i 0} {$i < 10} {incr i} {
     incr ::j [nextNumber]
   }

   # remove coroutine
   rename nextNumber {}

   ? {set ::j} 90
}

_______________________________________________
Xotcl mailing list
Xotcl_at_alice.wu-wien.ac.at
http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 27 Sep 2001 22:20:22 +0200

On Thursday 27 September 2001 17:06, you wrote:
> On Wednesday 26 September 2001 05:19 pm, you wrote:
> > A hugely important feature I would like to see in the near future,
> > and one I've asked about before, is for a good C&C++ interface. I know
> > this is not an easy issue to deal with, but for some things it would
> > actually be quite vital. For me, the normal application development model
> > would be to built everything in Tcl/XOTcl first, and then to begin
> > converting critical parts to C if better performance is required.

 This is certainly the way to go for many realword applications.
 we need two things
  (a) as everybody empahsized a good C-API
  (b) a conveniant way to integrate c and c++ code.

 SWIG is doing quite well on the C side. We have as well started to
 make a powerful C++ interface, that maps C++ classes into XOTcl classes.
 This way, it is possible to use C++ classes and objects together
 with mixins, filters etc., without even knowing the XOTcl C-API.
 what we have now is that C++ classes can be plugged into the
 XOTcl class hierarchy (sub- and superclassed, but e.g. no next
 from c++)

 What we did was for SWIG 1.3.6; what we did was mostly the C++ side.
 we won't have it ready for 0.9. Our code is still full of debug info,
 some of the code for interfacing c has do be done, some code of the
 c++ interface relies on the naming conventions of swig, so there is
 still some work to do. The newest release of SWIG is 1.3.9. if there
 are volunteers, to help out, these are very welcome.

 best regards
-gustaf

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 02 Feb 2006 23:33:36 +0100

Kristoffer Lawson schrieb:

> When XOTcl exits, it seems that the [destroy] method is called on all
> objects. The first question is whether this is wise .. possibly.


well, it was some work to do so, and i think this is important from the
oo-point-of-view.
If one allocates "external resources" (e.g. temp-files, register on a
whiteboard, etc)
and deallocates these resources in a destructor, the deallocation should
certainly
happen, when the program exists gracefully.

> The problem is I would like to build a transparent layer for
> persistence storage which could be applied to a wide range of
> applications. The problem naturally is that the objects in the
> persistence storage get destroyed when the application exits :-)

a strong coupling of the destruction of an xotcl object with its
persistent representation
is often not a good idea. For example, in the aolserver, persistent
objects will be used
in connection threads, which are created/terminated based on demand.

note, that also the creation of objects is in the persistent situation
different. When one creates
a new object, it is expected to be in a freshly initialized state. In
the persistent case,
you might want do decide, wether you want a fresh persistent object, or
a refetched
object from the last checkpoint. I use normally a fetch and delete method.
You can still call e.g. delete from the destructor if you need it....

-gustaf

>
> / http://www.fishpool.com/~setok/
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: <mail_at_xdobry.de>
Date: Fri, 23 Jan 2015 14:55:38 +0100 (CET)

Hi!
 
I have created XOTcl-Light package.
It is pure Tcl package on TclOO that provide XOTcl compatible system.
 
https://github.com/xdobry/xotcl-light
 
It is not full compatible and slower (more or less 50% slower than original
XOTcl)
but enough to run my own XOTcl programs.
 
All XOTcl-Light object are TclOO objects and can be modified introspected and
extended by TclOO code.
 
Incompatiblities
* no complex slot attributes. Only simple parameter similar to earlier XOTcl
versions.
* no complex forward syntax only TclOO forward
* no unknown mechanism for creating object from class (MyClass create myinst,
can not be written as MyClass myinst). It can be easy simulated but I do not use
it
* many introspection command does not support all options
* self is not modified and work like in TclOO
 
It is early version the work is ongoing.
Please report bugs.
 
Best Regards
Artur
 
 

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 1 Mar 2002 21:14:27 +0100

On Friday 01 March 2002 16:01, Lucio Travagnin wrote:
> Hi, I'm new to Tcl, XoTcl and Vignette, but I have to use these in a
> Project. XoTcl extensions can be used with vignette? Could I write some
> classes and then use them in Vignette Templates? Thank you

 Dear Lucio,

 i am not familiar with Vignettes story-server
 and i am not aware off anyone, who is using
 this combo (this does not mean to much).

 however, i would expect that the story server
 is able to load tcl-extensions. Correct?

 XOTcl is a TEA compliant tcl extension
 and requires Tcl 8.0 or newer. Therefore
 it should not be a problem to use this
 combination.

 Once you are able to load xotcl into the story-server
 you can use XOTcl classes and objects the same way
 you can use tcl-commands from the server.

 best regards
-gustaf neumann

>
> Lucio
>
> ___________________________________________________________________
> Lucio Travagnin
> Java & Perl Senior Developer - Interwoven Technical Manager
> ltravagnin_at_e-tree.com (ICQ 84914112)
>
> E-TREE - Internet Soul / Via Fonderia 43 - 31100 Treviso (Italy)
> phone +39.0422.3107 fax +39.0422.310888
> http://www.e-tree.comhttp://www.webanana.com
> ___________________________________________________________________

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Wed, 14 Oct 2015 14:23:12 +0200

Dear Michael,

most of the advanced slot features of XOTcl 1 were marked as
"experimental", which means, there is no guarantee, that this code will
work in future releases.

Below is something, which probably close enough to the legacy code. The
code enforces the creation of forwarder methods by using "-incremental
1". The multiplicity is set to 0..1 to be able to set attributes to ""
(default, later values)

xotcl::Class create Person -slots {
     foreach e {username first_names last_name email etcetera} {
        Attribute $e -default "" -multiplicity 0..1 -incremental 1
        $e proc value=set {o var value} {
            $o changed_var $var $value ${:default}
        }
     }
}
Person instproc changed_var {var value default} {
     if {$value ne $default} {lappend :__changed_vars $var}
     set :$var $value
}

Appending the variable names like in the legacy code is probably not a
good idea, since this means that when an attribute is set ten times,
then the variable name is listed also 10 times. I fail also to
understand, how the code detected changes from the database. It is
initializing all attributes with "", which are probably not the database
values. Somewhere the attributes must be properly initialized with the
database values (and __changed_vars should be reset), but what happens
with concurrent database updates? What should happen, when someone sets
the attribute first to a different value and then to default?

So i guess, the legacy-code was just a rough indicator for purposes like
"what attributes have non-default values", and for that purpose, the
code above should be useful as a start

Some background: Much of nx went from the purely method-based attribute
setters of XOTcl towards tk-like configure options.
In XOTcl it is very dangerous to have e.g. an attribute named "set", for
which an accessor method named "set" is generated, which will certainly
conflict with the predefined method "set". nx does not have this
problem, by using e.g. "... configure -set {...} ..."

best regards
-gn

Am 12.10.15 um 17:10 schrieb Michael Aram:
> Dear XOTcl/NX/NSF community,
>
> I am in the process of upgrading one of our OpenACS based systems to XOTcl
> 2 and stumbled over the following legacy code:
>
> Class create Person -slots {
> foreach e {username first_names last_name email etcetera} {
> Attribute $e -default "" -proc assign {o var value} {$o changed_var
> $var $value}
> }
> }
>
> Person ad_instproc -private changed_var {var value} {} {
> my instvar __changed_vars
> lappend __changed_vars $var
> my instvar $var
> set $var $value
> }
>
>
> The intention of this not-so-pretty code mainly seems to be that the
> Person->save method called by code like the following can recognize which
> attributes have actually changed during the last request, and update the
> database accordingly...
>
> Person john
> john last_name doe
> john save
>
>
> For some reason, now that I have upgraded the system to XOTcl 2, this does
> not work anymore. The list __changed_vars is not updated (in the example
> above, it would not contain last_name; for debugging purposes, I have put a
> log statement into the "assign" proc, it seems that it does not get called.)
>
> As the update process introduced many many other changes as well (compared
> to the old and adapted OpenACS we had there), including changes in
> xotcl-core, it could certainly be the case that this is simply a the
> side-effect of some other change / or messed-up merge. So, my question is,
> SHOULD this work anyway in the latest stable version of XOTcl 2, or did the
> interface change?
>
> Thanks for your help,
> Michael :-)
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Univ.Prof. Dr. Gustaf Neumann
WU Vienna
Institute of Information Systems and New Media
Welthandelsplatz 1, A-1020 Vienna, Austria

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Fri, 02 Apr 2004 13:40:36 +0200

Jim Lynch wrote:

>It's all in the configure step, so it's related to the configure.in
>file. The problems (all three) are all in that file.
>
>I may be able to fix the problems, but the issues are apparantly
>ongoing: I'm given to understand from the debian bug tracking system
>that these build problems have been going on for some time, and that
>xotcl was orphaned and removed from debian partly because of that.
>
>So while I'm willing to try fixing the problems, I'm not clear that my
>fixes would be welcomed.
>
>
xotcl is an open source project ... so we're happy about other people
helping out (actually
my opinion is: involvement other people is important in an open source
project to keep the community process going ... for instance: I wasn't
aware of the debian problem at all)
so I understand: you send us a patched configure.in which solves the
problem?

>>Regards,
>>
>>Uwe
>>
>>
>
>BTW, either I eliminated the possibility that the archive web site
>only archives 5 emails a month, or else someone fixed it for this
>month... the note you replied to is the 6th one for the month and
>it didn't replace the fifth.
>
>
>
there have been some server updates and 1-2 crashes because of a broken
memory
chip. maybe this problem relates to the backup.
our mails of today seem to be ok in the archive ... let's have an eye on
this. I've you experience further problems there, please drop us a note.

Uwe

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 16 Apr 2003 20:35:16 +0200

On Wednesday 16 April 2003 08:30, Michael A. Cleverly wrote:
> (Disclaimer: I'm quite new to XOTcl & I have read the tutorial a couple
> times but maybe not enough. :-)
>
> What's the XOTcl idiom/way for a static member variable (what snit, the
> only other OO Tcl package/extension I've used, would call a "type
> variable")?
>
> Contrived example: if I had a "Chapters" class, I'd like to have a single
> variable, accessible by all instances of the class, that kept track of the
> "current" chapter. Suggestions?

 Most of the important things were already answered by Neophytos and Kristoffer.
 XOTcl does not need a special construct, since every class is an object
 as well, and variables kept in a class are nothing special. Note that a
 programmer can decide what kind of class he is referring to:
  - the class which is the type of the object (via "my info class")
  - the current class, which is currently active (via "self class")
 The type variable you are refering to is the first one.

 Often, when people start to use XOTcl, there come requests how to achieve
 private instance variables. These can be easily achived through variable
 traces. Maybe someone finds the following code helpful or interesting....

=================================================================
Object instproc private {instvar args} {
  foreach var $args {
    my trace variable $var rwu [list [self] private_check]
  }
  uplevel "my instvar $args"
}
Object instproc private_check {var sub op} {
  if {[string compare [self] [self callingobject]]} {
    if {[string equal "" [self callingobject]]} {
      set context "global context"
    } else {
      set context [self callingobject]->[self callingproc]
    }
    array set paraphrase {w written r read u unset}
    error "private member $var of [self] $paraphrase($op) from $context"
  }
}
=================================================================

 Using this two instprocs, private instvars of an object can be declared.
 This is not a perfect solution but works quite well.....

================================================================
Class C
C instproc init {} {
  my private instvar x y
  set x 100
}
C instproc test {} {
  my set x 10
}
C instproc show {} {
  puts x=[my set x]
}

### test cases ###
C c1
c1 show
c1 test
c1 show
Object o1
o1 proc test0 {} { if {[catch {c1 set x 13} msg]} { puts "error: $msg" }}
o1 proc test1 {} { c1 instvar x; if {[catch {set x 13} msg]} { puts "error: $msg" }}
o1 proc test2 {} { if {[catch {c1 set x} msg]} { puts "error: $msg" }}
o1 proc test3 {} { if {[catch {c1 unset x} msg]} { puts "error: $msg" }}
c1 show
o1 test0
o1 test1
o1 test2
#o1 test3
c1 show
c1 set y 20
=======================================================

 If you want to use this test please apply the small patch below to
 allow correct error propagation through traces in XOTcl. There seems
 to be a small bug in the actual tcl-versions, since Tcl_UnsetVar2
 (which is used by xotcl unset) does not seem to propergate
 errors correctly from var traces as well....

=======================================================
--- xotcl.c~ Fri Mar 21 15:57:45 2003
+++ xotcl.c Wed Apr 16 19:00:35 2003
_at_@ -5978,7 +5978,7 @@
    * "init"). */

   if (!(obj->flags & XOTCL_INIT_CALLED)) {
- int newargs, result;
+ int newargs;
     /*
      * Call the user-defined constructor 'init'
      */
_at_@ -6986,8 +6986,7 @@
     Tcl_SetObjResult(in, result);
     return TCL_OK;
   } else {
- return XOTclVarErrMsg(in, "Can't find result of set ",
- ObjStr(objv[1]), 0);
+ return TCL_ERROR;
   }
 }
=======================================================

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien