Weblog Page

From: Kristoffer Lawson <setok_at_scred.com>
Date: Fri, 6 Aug 2010 00:28:44 +0300

On 5 Aug 2010, at 20:59, Gustaf Neumann wrote:

> you have lost all means to pass a value for "animal", except when you
> pass it to init (i know "new-with" is different). One can can certainly
> say, the first argument passed to init is the "animal", then default
> handling is ugly (in the general case) and you have to deal with ugly
> positional arguments. This technique does not scale:
> What, if one inherits additional parameters from a superclass
> (of Foo), or when the superclass is extended? If every argument
> to init corresponds to a parameter, one has to extend the signature
> of the involved init methods. Adding arguments is not really an
> option when the parameters are provided via mixins, or when
> the object-class and class-class relationships can changed dynamically.
> Another issue is passing arguments of init to superclasses via next.
> If the inits of the superclasses have different signatures, the
> code becomes error prone.

Gustaf, I'm not sure what you're getting at as that is exactly what [new-with] is for. With that I can do parameterisation outside of [init]. The idea is that then it is completely explicit that that is what I wish to do, and it has a fixed argument within which that takes place. So I use [new] when I do not need parameterisation (so I don't have to give an empty argument for [new-with]), and then [new-with] when I want parameterisation. Thus both cases are safe and explicit.

To reiterate: [new-with] is a script executed within the Object's environment (with [eval]) before [init] is called. Its job is to configure the object. It thus does mostly the same job as the normal parameterisation, but with a different approach.

The only reason for [new-with] is that I could not come up with another way to make absolutely explicit what the intention of an argument is, without bad data causing issues. That is why I was rambling with the list of suggestions, with different solutions. Each option could be made to work, so just a matter of taste.

I ended up with [new] and [new-with] for my own code for now, but offered the other options in my mind for discussion.

> My hypothesis is, that arguments for init are the poor men's
> approach for object parameterization, if one has nothing better.

Indeed, which is why I did not want to take them away. Perhaps this experiment of mine won't work well in practise. In particular, passing values from variables into the [new-with] script might end up being a nuisance. But for now it gave me peace of mind.

> Arguments to contructors come more often into discussion
> when porting c++ style programs to xotcl, rather than
> from intrinsics needs when coding in xotcl.

You may be right and that I should be using parameterisation more. Of course even then you do need to be careful what you pass.

> *Class create* Stack {
>
> *:method init* {} {
> *set* :things ""
> }
>
> *:method* push {thing} {
> *set* :things [*linsert* ${:things} 0 $thing]
> *return* $thing
> }
>
> *:method* pop {} {
> *set* top [*lindex* ${:things} 0]
> *set* :things [*lrange* ${:things} 1 end]
> *return* $top
> }
> }

Hm, am I right in assuming the *s are just something funny when you copy-pasted from your editor, or is the plan actually to have it look like that? I can feel a few eyebrows being raised if so! :-)

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

From: Colin Ross <colross_at_CROSSBEAMSYS.COM>
Date: Mon, 27 Apr 2009 17:44:12 -0400

Hi all ­ I have ported over one of our applications from using itcl to using
xotcl. I have a lot of code that already uses the itcl stuff, so the port
must be backwards compatible. I have the following issue. Can anyone give me
an idea how I can get around it? A script that shows my issue is as follows:

#!/usr/bin/tclsh
package req XOTcl
namespace import ::xotcl::*

::xotcl::Class Connect -parameter {
    {telnet}
    {ssh}
    {ip}
}
Connect instproc init {node args} {
    [self] instvar telnet
    [self] instvar ip
}

Connect dev node -ip "127.0.0.1" -telnet

The above does not work, as it seems that the ­telnet arg must not be NULL,
however, I need this to be NULL, as it is just a flag.

If I pass in:
Connect dev node -ip "127.0.0.1" -telnet ³²

This works, however, this is not backwards compatible with how things were
with itcl, and I have too many users/scripts to change how this is done.
There are potentially 2 ways around this, however, I am unable to find
information on if either of them are possible:
1. Allow the passing in of a NULL argument
2. Prevent the constructor parsing args so that I can parse my own


I would appreciate any assistance

Cheers
Colin

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 04 Jan 2012 11:00:56 +0100

Dear Victor,

While it is easy to provide a slim implementation, which
works nicely for particular cases, it is much more
complicated to provide a general solution that works for all
potential use cases.

Here are a few questions one has to address here:
* Most likely, one would expect something like a write-once
semantic via the property (declare the property, assign
later some value to it, etc.) rather than a true "const" (at
least when "property" rather than "variable" is used).
* Since Tcl variables can be altered in many ways (output
variables of cmds, resolver, ...) a true "const" must be
most likely realized via traces (which have often tricky
issues).
* it is not clear, whether "const" should imply different
write semantics, or as well different unset semantics. In
the latter case, when a destroy happens, one should
certainly unset the variables even when they are "const".
Also, copy/move operations tend to be tricky.
* when const is a slot property, we should address as well
cases for slots with additional semantics (such as
persistent, database-mapped slots, etc.)

Actually, my goal would even go further, by setting
optionally objects/classes immutable, but this is opening
some more cans of worms, but this opens as well some more
potential optimizations.

With have the "immutable" theme block on our todo list, but
not for the initial release.

-gustaf neumann

On 03.01.12 20:47, Victor Mayevski wrote:
> Thank you Gustaf and Sefan,
>
> Would it be possible to add that functionality into NX core? For example, via:
>
> Obj property {key:constant value}
> Obj variable key:constant value
>
> I know I can code it myself but I think programmers would prefer for
> it to be a built-in function.

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 18 Aug 2004 20:54:03 +0200

Dear XOTcl community,

i just fixed a small glitch in the serializer code (one can never have enough
regression tests :(). most likely, only aolserver users will be affected. please
refetch 1.3.0 from the server, if you have already got a copy of 1.3.0

-gustaf

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

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Mon, 14 May 2001 17:28:03 +0200

Hi,

at the moment there is no introspection support to find the "next" applied
mixin ... However, the new "self next" should return something like:

  XOTclClasses::UpdateMixin::update

in the filter. Unfortunately it overlooks mixins after a filter at the moment
... which is rather a bug. I'll fix it ASAP so that it'll work at least in
the coming (patch) release.

"calledclass" should not return the mixins because otherwise mixins are not
transparent for the client.

you can, of course, check for mixins with "info mixin" on [self]. And check
with "info instproc" for the calledproc


--Uwe





On Saturday 12 May 2001 09:48, you wrote:
> Hi,
>
> I have a filter on Object which purpose is to register the called procs
> of every class in my application, for debugging purpose.
> The list of called procs is then displayed in a graphical component where
> it can be selected to be traced
> (http://www-alt.pasteur.fr/~letondal/biok/Images/tracegui.gif).
>
> I would like to have also mixin procs registered, but apparently, the
> calledclass in the filter, when called on the mixin, does not return
> the mixin class, but the actual called class.
> Is there a way to know that the mixin proc was called - in the filter scope
> I mean ?
>
> This filter is put on every class during a given period:
> Object instproc spyFilter args {
> set proc [self calledproc]
> set class [self calledclass]
>
> # debug is an Object doing debugging tasks and registering
> # trace/debug informations
>
> debug instvar calledprocs
> lappend calledprocs($class) $proc
> }
>
> Class UpdateMixin
> UpdateMixin instproc update args {
> ....
> }
>
> UpdateMixin filter actually displays spyFilter, but the filter
> does not "see" the UpdateMixin as the calledclass, but rather the
> class the mixin is associated with.
>
> Thanks for your help,
>
> --
> Catherine Letondal -- Pasteur Institute Computing Center
>
>
>
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_wi.wu-wien.ac.at
> http://wi.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_{xotcl.org,computer.org}, uwe.zdun_at_uni-essen.de

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 24 Oct 2006 11:54:54 +0300

> configure gets all arguments, including the values passed to init.
> Use the one-liner of my last mail, and you
> will see that this works for your example as well. if you pass the
> saved values to object creation, you achieve
> both, configuring the attributes and calling the constuctor with
> the saved values.

OK, thanks, this is working for me at the moment.

> mixins are in no way more "risky" than a filter or overloading
> "create". The mixins are in the precedence order
> before the intrinsic class tree. So, it does not matter whether or
> not someone has overloaded in the intrinsic
> class tree "configure", and/or forgotten to write a next there.

Yup, I got confused about the calling order, thinking that mixins are
called after the other inheritance chain.

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 16 Mar 2001 19:30:12 +0100

 Here is a small fun-example of a Tk program translated to XOTcl.
 Start it with xowish

enjoy
-gustaf
=====================================================================================
 #!/usr/local/bin/xowish
# Example by <Richard Suchenwirth> translated from Tcl to XOTcl by gustaf neumann
# Left mousebutton starts, middle slows down, right stops
package require XOTcl

Class Wheel -parameter {r x y {spokes 24} {pivot 0} {color red} {tag ""}}
Wheel instproc drawSpokes {} {
  [[self] info parent] instvar c alpha
  [self] instvar W color spokes r x y
  set delta [expr {360./$spokes}]
  set deg2arc [expr {atan(1.0)*8/360.}]
  for {set i 0} {$i<$spokes} {incr i} {
    set x1 [expr {$x+cos($deg2arc*$alpha)*$r}]
    set y1 [expr {$y+sin($deg2arc*$alpha)*$r}]
    $c create line $x $y $x1 $y1 -fill $color -tag spoke
    set alpha [expr {$alpha+$delta}]
  }
  if {[[self] exists act_pivot]} {
    foreach {item perc} [[self] set act_pivot] break
    set rp [expr {$r*$perc}]
    set xp [expr {$x-$rp*cos($deg2arc*$alpha)}]
    set yp [expr {$y-$rp*sin($deg2arc*$alpha)}]
    $c coords $item $xp $yp [expr {$xp+1}] [expr {$yp+1}]
  }
}
Wheel instproc init {} {
  [[self] info parent] instvar c alpha
  [self] instvar pivot color tag W r x y
  set alpha 0.
  set y [expr {$y-$r}]
  $c create oval [expr {$x-$r}] [expr {$y-$r}] [expr {$x+$r}] [expr {$y+$r}] \
      -outline white
  set r1 [expr {$r-2}]
  set W [$c create oval [expr {$x-$r1}] [expr {$y-$r1}] [expr {$x+$r1}] \
             [expr {$y+$r1}] -outline $color -width 2]
  [self] drawSpokes

  if {$pivot} {
    set deg2arc [expr {atan(1.0)*8/360.}]
    set rp [expr {$r1*$pivot}]
    set xp [expr {$x-$rp*cos($deg2arc*$alpha)}]
    set yp [expr {$y-$rp*sin($deg2arc*$alpha)}]
    set new_pivot [$c create rect $xp $yp \
                       [expr {$xp+1}] [expr {$yp+1}] -fill $color \
                       -tag [list $tag pivot]]
    [self] set act_pivot [list $new_pivot $pivot]
     
    $c create arc [expr {$x-$r1}] [expr {$y-$r1}]\
        [expr {$x+$r1}] [expr {$y+$r1}] \
        -style chord -fill $color -start 310\
        -extent 80 -tag counterweight
    set pivot $new_pivot
  }
  set rh [expr {$r/12.}]
  $c create oval [expr {$x-$rh}] [expr {$y-$rh}] [expr {$x+$rh}] \
      [expr {$y+$rh}] -fill white -tag hub
  set r $r1
}

Class Railroad -parameter {{speed 4}}
Railroad instproc turn {} {
  [self] instvar c alpha speed
  set alpha [expr {round($alpha+360-$speed)%360}]
  foreach i [$c find withtag counterweight] {
    $c itemconfig $i -start [expr {310-$alpha}]
  }
  $c delete spoke
  foreach wheel [[self] info children] { $wheel drawSpokes }
  $c raise hub
  set xp0 [expr {105+15*sin(($alpha-90)*atan(1.0)*8/360)}]
  $c delete piston
  eval $c coords p0 $xp0 120 [expr {$xp0+2}] 122 ;#CW
  $c create line 90 121 $xp0 121 -width 2 -fill white -tag piston ;#CW
  [self] drawRod p0 p1 p2 p3
  $c raise p0
  foreach i [$c find withtag smoke] {
    if {[lindex [$c bbox $i] 3]<0} {
      $c delete $i
    } else {
      $c move $i [expr {rand()*$speed/3.}] [expr {rand()*2-2}]
    }
  }
  set t [eval $c create oval [$c bbox chimney] -fill white -outline white -tag smoke]
  $c move $t 0 -10
  $c lower smoke
}
Railroad instproc drawRod {p0 p1 p2 p3} {
  [self] instvar c
  $c delete rod
  eval $c create rect [$c bbox $p1 $p3] -fill white -tag rod
  eval $c create line [lrange [$c bbox $p0] 0 1] \
      [lrange [$c bbox $p2] 0 1] -width 3 -fill white -tag rod
  $c raise rod
  $c raise pivot
}
Railroad instproc tick {} {
  [self] turn
  foreach i [after info] {after cancel $i}
  after 10 [self] tick
}
Railroad instproc throttle {} {
  [self] incr speed 6
  [self] tick
}
Railroad instproc break {} {
  [self] incr speed -2
  if {[[self] set speed]<0} {[self] set speed 0}
  [self] tick
}
Railroad instproc emergencyBreak {} {
  [self] set speed 0
  [self] tick
}

Railroad instproc init {} {
  [self] instvar c
  set c [canvas .c -width 600 -height 160 -background lightblue]
  pack $c

  bind $c <1> [list [self] throttle]
  bind $c <2> [list [self] break]
  bind $c <3> [list [self] emergencyBreak]

  $c delete all
  $c create rect 32 115 360 125 -fill black ;# frame
  $c create rect 22 118 32 122 -fill grey30 ;# buffer
  $c create line 22 115 22 125
  $c create poly 60 95 40 115 50 115 70 95 -fill black
  $c create rect 60 45 310 95 -fill grey25 ;# boiler
  $c create oval 55 50 65 90 -fill black ;# smokebox
  $c create rect 70 32 85 50 -fill black -tag chimney
  $c create rect 40 52 90 75 -fill black ;# wind diverter
  $c create oval 130 36 150 52 -fill black ;# dome
  $c create rect 195 35 215 50 -fill black ;# sandbox
  $c create oval 260 36 280 52 -fill black ;# dome
  $c create rect 65 100 90 135 -fill black ;# cylinder
  $c create rect 90 120 92 122 -fill red -tag p0 ;# crossbar
  $c create rect 72 87 82 100 -fill black ;# steam tube
  $c create rect 310 40 370 115 -fill black ;# cab
  $c create rect 310 32 390 42 -fill grey30 ;# cab roof
  $c create text 338 82 -text "01 234" -fill gold -font {Times 7}
  $c create rect 318 48 333 66 -fill white ;# cab window #1
  $c create rect 338 48 355 66 -fill white ;# cab window #2
  Wheel newChild -x 50 -y 150 -r 13 -spokes 12
  Wheel newChild -x 105 -y 150 -r 13 -spokes 12
  Wheel newChild -x 150 -y 150 -r 30 -pivot 0.5 -tag p1
  Wheel newChild -x 215 -y 150 -r 30 -pivot 0.5 -tag p2
  Wheel newChild -x 280 -y 150 -r 30 -pivot 0.5 -tag p3
  [self] drawRod p0 p1 p2 p3
  Wheel newChild -x 340 -y 150 -r 16 -spokes 12
  $c create rect 360 110 380 118 -fill black
  $c create rect 380 65 560 125 -fill black -tag tender
  $c create rect 560 118 570 122 -fill grey30 ;# buffer
  $c create line 571 116 571 125
  $c create rect 390 45 525 65 -fill black -tag tender
  Wheel newChild -x 395 -y 150 -r 13 -spokes 12
  Wheel newChild -x 440 -y 150 -r 13 -spokes 12
  $c create rect 380 132 456 142 -fill red
  Wheel newChild -x 495 -y 150 -r 13 -spokes 12
  Wheel newChild -x 540 -y 150 -r 13 -spokes 12
  $c create rect 480 132 556 142 -fill red -outline red
  $c create rect 0 150 600 160 -fill brown ;# earth
  $c create line 0 150 600 150 -fill grey -width 2 ;# rail
  [self] tick
}

Railroad r

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Tue, 29 Aug 2006 20:20:16 +0200

well, why do you think the behavior breaks encapsulation? Rather a
behavior where mixin are not added in precedence before the class
hierarchy, requires you to know about the interceptor and might break
encapsulation. Consider you are omitting to use "next" in a method of
Derived, for instance simply because this method exists nowhere else in
the class hierarchy. If the mixin would be introduced after Derived, you
would need to modify Derived to introduce a method of the same name on
the mixin. If the mixin is always before the class hierarchy, as a base
hierarchy developer you don't need to care for how a potential mixin is
designed, because you can be sure once a call has reached your class,
you can be sure, you cannot accidently introduce side-effects on mixins
(maybe designed later by other developers).

Scott Gargash wrote:

>
> As I understand it, precedence order is computed as filters then
> mixins the superclasses, and this sort order is applied "globally" to
> an object.
>
> In other words:
>
> Class create Base
> Class create Derived -superclass Base
> Derived d
> d info precedence ==> ::Derived ::Base ::xotcl::Object
>
> Class create BaseMixin
> Base instmixin add BaseMixin
> d info precedence ==> ::BaseMixin ::Derived ::Base ::xotcl::Object
>
> This behavior seems to violate encapsulation. BaseMixin is intended to
> intercept messages to Base. Derived doesn't know about BaseMixin and
> BaseMixin doesn't know about Derived, yet BaseMixin ends up being the
> first interceptor of messages to Derived.
>
> Since BaseMixin is intended to modify the behavior of Base, it would
> be better BaseMixin preceeded Base (and only Base) in the sort order.
>
> d info precedence ==> ::Derived ::BaseMixin ::Base ::xotcl::Object
>
> The current behavior means you can't really add a mixin without
> understanding everywhere that the object being extended is used. Is
> there some benefit to the current behavior that I don't understand?
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Xotcl mailing list
>Xotcl_at_alice.wu-wien.ac.at
>http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
>

From: Zoran Vasiljevic <zoran_at_munich.com>
Date: Fri, 8 Dec 2000 04:06:00 -0500 (EST)

------Original Message------
From: <uwe.zdun_at_uni-essen.de>
To: Zoran Vasiljevic <zoran_at_munich.com>
Sent: November 21, 2000 1:36:57 PM GMT
Subject: Re: XOTcl 0.83 questions (continued...)


>here, is some example code that shows two ways how to retrieve >all
instances, classes, and metaclasses in the system:

Hi !

Thanks for this good example. But I still somehow have
problems. The main problem is the ORDER! What I need to
do is run a script against an initialized interpreter
and construct another script which will replicate all
XOTcl objects, classes etc,etc in an fresh interpreter.
So the *ORDER* of commands is crucial.

If somebody says:

Class Foo
Class Bar -superclass Foo

Then the introspection script !!!MUST NOT!! emit:

Class Bar -superclass Foo
Class Foo

The example below seems not to care about the order.
The "allObjs" list below has all objects, right, but
the order is not preserved, or not correctly computed.

So I would *realy* appreciate if somebody could point
me to the right direction. I apologize If I'm being to
ignorant or stupid. Maybe this is just another piece of
cake for XOTcl experts but for me (as XOTcl beginner)
it's not!

Thanks,
Zoran Vasiljevic


--------------

###################################################################

# set up some classes for testing

#
# some meta classes
#
Class Meta -superclass Class
Class Meta2 -superclass Meta
Class Meta3 -superclass Meta2
#
# some classes
#
Class X
Class Y
Meta Z
Meta2 A
Meta2 B
#
# some objs
#
X x
Object o
Y y1
Y y1
A a1
A a2

#
# if you only use the global namespace it is quite simple to retrieve
# the instances, like:
# (you can also traverse the namespaces ... but then the
# variant down below is more elegant)
set objects ""
foreach c [info commands] {
if {[Object isobject $c]} {lappend objects $c}
}
puts "Global Objects are: $objects"



#
# we can also go along the class hierarchy
#
# we define a separate class that computes the instances (could
# also be instprocs on Object ... but then we won't have the ability
# to use the code on a subclass)
#

Class InstanceRetrieval

InstanceRetrieval instproc getAllSubClasses cl {
set result ""
set sc [$cl info subclass]
foreach c $sc {
lappend result $c
set result [concat $result [[self] getAllSubClasses $c]]
}
return $result
}

InstanceRetrieval instproc getAllInstances {} {
set result ""
# get all subclasses of this class
set subclasses [[self] getAllSubClasses [self]]
# now get the instances of every subclass
foreach sc $subclasses {
set result [concat $result [$sc info instances]]
}
return $result
}

# now we register that class on Object as a mixin
# -> we can all instances of the object class (including the
# nested objects

Object mixinappend InstanceRetrieval
set allObjs [Object getAllInstances]
puts "All objects are: $allObjs"

#
# with isclass and ismetaclass we can additionally sort out the
# classes and metaclasses
#

foreach o $allObjs {
if {[Object isclass $o]} {
lappend classes $o
if {[Object ismetaclass $o]} {lappend metaclasses $o}
}
}

puts "All classes are: $classes"
puts "All metaclasses are: $metaclasses"

###################################################################


______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Mon, 08 Feb 2010 19:47:50 +0100

Dear Koen,

we are busy working on xotcl 2.0, which works for tcl 8.5 and tcl 8.6
(we will most probably not be able to make 2.0 work with tcl 8.4;
the 8.4 support is still in the 2.0 code base, but getting it to work
with 8.4 would require a lot of work, so we will skip it).

i am currently in the midst of reworking slots, which is the
last biggy before the release (which i hoped to get finished
by end of 2009)). There will be some more polishing on
the interfaces and the code, documentation is at an early
state, so end of q1 seems in reach for the release.

xotcl 2.0 is quite different from xotcl 1.*, but there
is an xotcl 1.* layer available, which is highly backwards
compatible (i have tested it e.g. against xotcl-core and xowiki
inside openacs, about 46000 lines of code). in case, you have
not seen the slides an the xotcl 2.0 paper, drop me a note.

if you have interest on getting access to the development version
of xotcl 2.0, i can give you access to the git repository.

-gustaf neumann

Am 08.02.10 18:17, schrieb Koen Danckaert:
> Dear XOTcl developers,
>
> I'm trying to use XOTcl (1.6.5) with Tcl8.6.
>
> Apparently XOTcl does not compile with Tcl8.6, but on Linux, I can get it to work by using a version compiled for Tcl8.5.4.
>
> However, this is not the case on Windows: loading XOTcl will make Tcl8.6 crash there.
>
> I also tried to use the xotcl165.dll provided by Activestate in the Tcl8.6b1 distribution. This seems to work with Tcl8.6b1 indeed, but not with newer versions of Tcl fetched from CVS (which I need).
>
> Is it possible today to use XOTcl in a recent Tcl8.6 ?
> Or are there any plans to update XOTcl ?
>
> Best regards,
> Koen Danckaert
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

-- 
Univ.Prof. Dr. Gustaf Neumann
Institute of Information Systems and New Media
WU Vienna
Augasse 2-6, A-1090 Vienna, AUSTRIA