Weblog Page

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Mon, 26 Sep 2005 10:40:02 -0700

I know that many on this list will be interested in the
following TIP just propsed:

        TIP #257: Object Orientation for Tcl
        http://www.tcl.tk/cgi-bin/tct/tip/257

This is indeed based on xotcl, but it is *not* xotcl. There
are good reasons for this overall (but not necessarily for
each individual change ;) ). I would like xotcl users who
are interested to please read this TIP carefully, but to
bear a few items in mind:

1. We know that syntax will change. Some is terminology, and
not all features are being adopted. This is not intended to
be a TIP to include all of xotcl, but rather to provide a
well featured oo:: base. itcl, snit and whatever isn't
included from xotcl should be easily built on this base. At
the same time, xotcl as an independent code base will
continue to work just fine.

2. Not all Tcl users are OO lovers. Some are just OO
agnostic and want to remain that way (like all the non-CS
technical folks). For those who like OO, most come from OO
worlds dominated by Java. Terminology that they will be
familiar with is important. At the same time, we want to
create the best system for Tcl (and Tcl is better than Java).
The oo::tcl approach at least tries to address this without
losing many of the benefits of XoTcl.

3. Megawidget support - whatever the solution it absolutely
must be consistent with the goals of bringing a standard
megawidget facility to Tk. I personally use snit::widget
for this, with its delegation based system. I have not
seen any other system come close to its ease of megawidget
development (including xotcl based ones). Many of the
large systems in Tcl are Tk-based, and they will benefit
greatly from standardized OO. However, if the system isn't
"Tk friendly", it will be rejected.

I'm sure there are lots of other good, pithy comments I
could make, but I'll let you guys (and gals) digest the
basics first.

Regards,

  Jeff Hobbs, The Tcl Guy
  http://www.ActiveState.com/, a division of Sophos

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Tue, 28 Sep 2010 03:03:19 +0200

Neil,

Interesting catch (though hairy)!

> I am having a problem/have found a bug with slots created with an
> -initcmd.
> If I set a value on an object containing a slot with an initcmd and then
> move it an error gets thrown every time I read the value.

The reason for this erratic behaviour is that the move (as well as the
copy) operation does NOT handle the transfer of variable traces properly.
Some background: The ::xotcl::Attribute infrastructure uses Tcl variable
traces to indirect operations (/obj/ set ...) on object variables to
their respective attribute slot objects. When moving an object (x),
these traces are supposed to migrate to the new or target object (y).

This migration action, however, is currently (1.6.6) broken:

a) the variable trace commands carry the name of the source object
(::x). for now, the occurrences of the source object's name in the
command statement are not replaced by the target object's name. hence,
the error:

> can't read "a": invalid command name "::x"

(as it should by "::y" after the move!)

b) investigating this issue, I found that the migration action of var
traces leads to an unwanted accumulation of trace definitions on the
respective target objects (e.g., two initcmd scripts being eval'ed on
::y, rather than one!).

i came up with a fix against 1.6.6. as i am not sure whether it will
make it into a patch release in this shape (and assuming that you cannot
upgrade to such a patch release), i refactored the patch into something
ready-made. I tested it with initcmd, valuecmd, and valuechangecmd.
there might be a more straight-forward approach for your deployment
scenario, however, this one hasn't crossed my mind yet.

namespace eval ::xotcl::unsupported {
   namespace import ::xotcl::*

   Class create Copyable \
       -instproc clear_variable_traces {obj var op trace_cmd {max 1}} {
        set traces [$obj trace info variable $var]
        set occurrences [llength [lsearch -all -exact $traces [list $op
$trace_cmd]]]
        while {$occurrences > $max} {
          $obj trace remove variable $var $op $trace_cmd
          incr occurrences -1
        }
       } -instproc __default_from_cmd {obj cmd var sub op} {
        set trace_cmd [list [self] [self proc] $obj $cmd]
        my clear_variable_traces $obj $var $op $trace_cmd 0
        next
       } -instproc __value_from_cmd {obj cmd var sub op} {
        set trace_cmd [list [self] [self proc] $obj $cmd]
        my clear_variable_traces $obj $var $op $trace_cmd
        next
       } -instproc __value_changed_cmd {obj cmd var sub op} {
        set trace_cmd [list [self] [self proc] $obj $cmd]
        my clear_variable_traces $obj $var $op $trace_cmd
        next
       }

   ::xotcl::Attribute instmixin add Copyable

   Class create FixedCopyHandler -instproc copyTargets {} {
     next
     foreach origin [my set targetList] {
       set dest [my getDest $origin]
       foreach var [$dest info vars] {
        set cmds [$dest trace info variable $var]
        foreach cmd $cmds {
          foreach {op def} $cmd break
          $dest trace remove variable $var $op $def
          foreach idx [lsearch -exact -all $def $origin] {
            lset def $idx $dest
          }
          $dest trace add variable $var $op $def
        }
       }
     }
   }

   ::xotcl::Object::CopyHandler instmixin add FixedCopyHandler
}


hope it helps,
//stefan

From: Artur Trzewik <mail_at_xdobry.de>
Date: Mon, 1 Jul 2002 18:02:34 +0200

Hi!

The Integrated/Interactive Development Environment for XOTcl
The new version of XOTclIDE 0.31 is ready on
http://www.xdobry.de/xotclide

The Changes from last annouced Version 0.30
- support for odbc (per tclodbc) and postgres (additonal to mysql) as
  version-control database
- better ms windows support
- new starter procedures
- syntax highlighting for comments and "quotas"
- tcl comment scanner (scan # comments)
- html doc generator
- other small changes

have fun with it

Artur Trzewik

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Sat, 19 Apr 2003 15:29:18 +0200

If you add a simple output message:
  puts *********[self calledproc]
to the singletonCreateFilter you can see that the only methods (other than
create) that pass the filterguard are those that are called before the
filterguard is active. Here this is only the method "filterguard" itself.
This cannot be avoided as you register filter/filterguard directly on the
instance:

> $class filterappend singletonCreateFilter
> $class filterguard singletonCreateFilter \
> {[self calledproc] == "create"}

actually this is not the best solution because any instance of the mixin
requires this filter. Better you register it as an instance filter for the
mixin:

Singleton instfilterappend singletonCreateFilter
Singleton instfilterguard singletonCreateFilter \
    {[self calledproc] == "create"}

that also avoids that other methods than create are dispatched to the filter,
as no other method is called on the instance (here: C) between filter and
filterguard registration. Once the guard is registered only create passes it.

--uwe


On Saturday 19 April 2003 07:40, Michael A. Cleverly wrote:
> As I'm starting to learn XOTcl, I decided to try and implement a singleton
> design pattern as an educational exercise.
>
> Here is what I've come up with see below). I'd appreciate help
> understanding why my filterguard registration does not work as I'd expect
> it to. (I'd also appreciate feedback on style, or if my comments
> indicate a misunderstanding of what the code actually does, etc.)
>
> Thanks again for all the help.
>
> Michael
>
> #!/bin/sh
> # -*- tcl -*- \
> exec tclsh $0 ${1+"$_at_"}
>
> package require Tcl 8.4
> package require XOTcl 1.0
> namespace import -force xotcl::*
>
> Class Singleton
> Singleton instproc singletonCreateFilter args {
> # Despite adding a filterguard (see below) for some reason
> # the "C foo" below would fail because a singleton instance of
> # class C exists ("::singletonCreateFilter" ?!??) if we don't also
> # check to make sure [self calledproc] == create here.
> #
> # I don't understand why ...
> if {[self calledproc] != "create"} {
> return [next]
> }
>
> [self class] instvar singletons
> set obj [lindex $args 0]
> set class [self]
>
> # if the object name isn't a fully qualified name make it so
> if {![string match ::* $obj]} {
> set obj [namespace parent]::$obj
> }
>
> # don't throw an error if we're recreating the same object
> if {[info exists singletons($class)] &&
> [string equal $singletons($class) $obj] == 0} {
> error "Can't instantiate \"$obj\" of singleton class\
> \"$class\"; \"$singletons($class)\" already instantiated"
> }
>
> set singletons($class) $obj
> next
> }
>
> Singleton instproc singletonDestroyFilter args {
> [self class] instvar singletons
>
> set class [my info class] ;# equiv of [self] info class
>
> # if other objects existed before Singleton registerClass
> # was called, and those objects are deleted, we don't care
> if {$singletons($class) == [self]} {
> unset singletons($class)
> }
>
> next
> }
>
> Singleton proc registerClass class {
> my instvar singletons
> my instvar registered
>
> # make sure we're dealing with a class
> if {[my isclass $class] == 0} {
> error "\"$class\" isn't a class;\
> hence, can't make it a singleton class."
>
> }
>
> # Don't "double register" a class
> if {[info exists registered] &&
> [lsearch -exact $registered $class] != -1} then return
>
>
> # We need to mixin to the object to filter the obj creation
> # We need to mixin to the class to filter obj destruction
> $class mixinappend [self]
> $class instmixinappend [self]
>
> $class filterappend singletonCreateFilter
> $class filterguard singletonCreateFilter \
> {[self calledproc] == "create"}
>
> $class instfilterappend singletonDestroyFilter
> $class instfilterguard singletonDestroyFilter \
> {[self calledproc] == "destroy"}
>
> lappend registered $class
> }
>
> Singleton proc create args {
> # doesn't make sense to instantiate objects of the singleton class
> error "Can't instantiate an object of \"[self]\";\
> use \"[self] registerClass className\" instead."
> }
>
> Class C
>
> # just a quick sanity check to make sure our filter doesn't
> # keep us from defining instance procs or using them
> C instproc datetime {} {
> clock format [clock seconds]
> }
>
> Singleton registerClass C
>
> # don't expect/don't want [C foo] to fail
> C foo
> puts [foo datetime]
>
> # We expect/want [C bar] to fail
> C bar
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 18 Jul 2006 15:11:15 +0200

Dear Florian,

info parameter has a well known bug that it returns just the value of
the last parameter invocation for the class.
to get the full list, you have to do something like

    X parameter {{p1 val1}}
  ...
    X parameter [concat [X info parameter] {{p2 val2} {p3 val3}}]

There is an undocumented feature to access the default values via:

    puts d=[X set __defaults(p1)]

note that this might change in the future.

i have locally a complete rewrite of the parameter system of xotcl based
on single and multivalued slots,
but i have still to implement an as-far-as possible backward compatible
top-level layer for it.
It waits as well for a stress and feature test for a relational database
layer we are developing,
but anyhow, it should become part of the next release of xotcl.

greetings
-gustaf

Murr, Florian schrieb:
> package require XOTcl
> namespace import xotcl::*
>
> # Let's say, I got:
>
> Class X -parameter {
> {p1 val1A}
> }
> X create x1 -p1 x1val1
>
> # ...
>
> # Now I change the default-values
> X parameter {
> {p1 val1B}
> }
> X create x2 -p1 x2val1
>
> # How do I get the current default-value 'val1B' for p1?
> # Note 'X info parameter' is no option, since after:
>
> X parameter {}
> puts "X parameter = [X info parameter]"
> X create x3
> puts "x3 p1 --> [::x3 p1]" ;# still works.
>
> # So the default-values are remembered somewhere!
> # My guess was somewhere around '::xotcl::Class::Parameter', but I
> just
> # could not find, where? - and how to access them?
> #
> # Somehow there must be a better way to access the current
> default-values
> # then via some newly created dummy object?!
>
> # (May be even the "old" default-values 'val1A, val2A' (for ::x1)
> are still remembered somewhere?)
> #
> # regards,
> # - Florian
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 5 Feb 2001 23:28:30 +0200 (EET)

On Mon, 5 Feb 2001, Rick Hedin wrote:

> Hi Kristoffer.
>
> This behavior seems correct. You are trying to pass three arguments:
>
> 1. myArg 2. -whatever 3. niceSystem
>
> to one formal parameter:
>
> arg
>
> We could send one argument:
>
> next {myArg -whatever niceSystem}
>
> or use the special properties of the args keyword:
>
> Foo instproc init {args} { . . .
>
> Am I looking at this right?

No, that wasn't the point. When normally creating an object you
can call other methods along with the initialisation procedure
(this is mentioned in the section of the tutorial about parameters,
IIRC). So the following works:

Class Foo
Foo instproc init {arg} {
  puts "arg: $arg"
}
Foo instproc anotherMethod {param} {
  puts "param: $param"
}

set foo [Foo new initArg -anotherMethod methodParam]

Output:
param: methodParam
arg: initArg

This can often be extremely handy (and a nice feature of XOTcl). But
apparently this does not work with [next] and init. It's not exactly
documented that it doesn't work, but it would feel natural to assume that.

         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

From: Donal K. Fellows <donal.k.fellows_at_manchester.ac.uk>
Date: Thu, 29 Sep 2005 00:04:13 +0100

Gustaf Neumann wrote:
> Donal K. Fellows schrieb:
>> BTW, I was wondering what happens when you do this in XOTcl (ignoring
>> the syntax for now):
>>
>> class A derived from Object
>> defines instproc foo
>> class B derived from A
>> defines instproc bar
>> class C derived from Object
>> defines instprocs foo, bar and move
>>
>> object D is a C with B mixed in
>> call: D foo
>> call: D move
>>
>> Which implementation of foo gets called first? Which implementation of
>> move gets called first?
>
> as kristoffer pointed out, there is only one move, so there is no
> ambiguity.

There are two 'move' methods/instprocs. One is in the XOTcl base Object
class, and one is in C.

> In general the precedence order is
> per-object-mixins per-class-mixins self-procs class-hierarchy
>
> The introspection command for this is
> D info precedence

Perhaps I should explain more about what I was asking about. :-)

What I did was I constructed the situation according to the attached
diagram (sorry to everyone for doing an attachment, but I refuse to do
ASCII art for this!) and what I wanted to know was, given that we've got
a per-object mixin, would the foo inherited from A by B be mixed in at
higher precedence than the foo gained by D directly from C. If that's
the case, would the move inherited from Object through the mixin side
override the move gained directly from C? As far as I can tell as
someone who has not thought about this in detail, that's the only way to
do this sort of thing consistently. But it also means that mixins will
stamp all over any attempt to redefine behaviour for a particular
application domain. If I'm wrong and I've overlooked something, what is
it? It's certainly not clear to me. (Mind you, it's midnight as I write
this so the old braincells might not be producing maximum clarity
anyway. ;-) )

I hope this all explains why I was asking what appears to be on the
surface a trivial question, and the answer should clear up the details
of what I don't know about XOTcl inheritance rules from reading the
documentation.

Donal.

From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Mon, 18 Dec 2000 13:35:55 +0100 (CET)

>>>>> "CL" == Catherine Letondal <letondal_at_pasteur.fr> writes:
CL> Hi,
CL> I have a very philosophical question :-)
CL> I would like to replace inheritance by delegation for some
CL> classes' instances.

CL> e.g:
CL> Class C -parameter {delegate} # instead of Class C -superclass D
CL> C c -delegate a

CL> where a is an object of another class, say class A.

CL> Delegation means that:
CL> - next should call the delegate's proc/instproc
CL> - set, instvar would give access to delegate's variables
CL> (this is one of the classical delegation mechanisms/behaviour I believe?)


 Dear Catherine,

 Your definition is not the standard definition of delegation, since
 delegation is not related with the ideas of "next". Informally,
 delegation means: don't do everything by your[self], use another
 object to help you. Normally, delegation is pretty much hardwired to
 the code.

 What you are trying to do is certainly very interesting. What you are
 facing is however, the "inverse self problem" (Lieberman observed,
 that through delegation, you easily loose the [self]-reference to the
 callee, the method called via delegation has a different [self]; by
 the means of mixins or filters, we tried to find alternate ways to
 achieve, what delegation does, but now you seem to want delegation,
 and you use filters and mixins, and you wonder how to get the self of
 the delegate ... therefore i called the problem "inverse self
 problem"). Somehow i doubt that you will be happy just by using
 instvars in the delegate, i assume you want real delegation.

 The problem is that by using "next", "mixins" etc. you do not change
 the active object ([self]), which is certainly quite an important
 assumption. I have to be convinced that this is too limited.

 Below is a simple implementation, which can be made nicer by using
 mixins or filters, but which is quite easy to understand and could
 help you as a starting point. Most likely, you will want to use
 "handleDelegation" for all methods, therefor a filter would be
 appropriate, but maybe, you want to try delegation for a set of
 methods, therefor you could use instmixins

 Suppose, an object a1 of class A wants to call a method "m". Method m
 has a stub for "m" that checks, whether it can delegate it (to object
 d1 of D) and delegates it if possible, otherwise it handles it by
 itself.

 Note, that this works fine without to much interference with the
 mixins/subclasses/... for A, a1, D, d1, instvars pose no problems,
 etc. It is fairly trivial to extend this program to handle multiple
 delegation objects...

 best regards
-gustaf

=========================================================================

Class A -parameter delegate
A instproc handleDelegation {result} {
  if {[[self] exists delegate]} {
    set context [::info level -1]
    # look for the called method in the delegated object
    if {[[[self] set delegate] procsearch [lindex $context 0]] != ""} {
      ::upvar $result r
      set r [eval [[self] set delegate] $context]
      return 1
    }
  }
  return 0
}
A instproc m {x} {
  if {[[self] handleDelegation r]} {return $r} else {
    puts "[self] [self class] [self proc] $x";
    return [next]
  }
}

Class D
D instproc m {x} {
  puts "[self] [self class] [self proc] $x"
  next
  return [expr {$x*2 + [[self] set v]}]
}

D d1
d1 set v 100
A a1 -delegate d1


puts "result=[a1 m 123]"
=========================================================================

From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Tue, 6 Feb 2001 13:11:05 +0100 (CET)

>>>>> "CL" == Catherine Letondal <letondal_at_pasteur.fr> writes:
CL> Gustaf Neumann wrote:
RH> Or wrap every tk command in my xotcl object.
>>
>> Sometimes, this is a straight forward solution to keeps the
>> XOTcl objects and the tk widget in separate trees. Architecturally,
>> this is not a beauty.

CL> How do you then implement the composite pattern for widgets trees as
CL> explained in:

  ...
CL> In my application, every Tk widget creation is wrapped in a method:
CL> widgets build ${frame}::widgets::panel {
CL> frame $path.panel
CL> }
CL> where widgets is of class Object.

 my point is not that you can't do it, the point is that it can be
 done in many ways, but we have for now no definitive best
 solution. The main problem is that often there are other Tcl commands
 (pure Tcl, [incr tcl], tk, ...) that we want to treat like first
 class XOTcl objects. A mechanism suited for Tk is not necessarly the
 best for [incr tcl] or other situations. We are using some ad-hoc
 approaches for the problem already for "package" (see package.xotcl)
 or file (see make.xotcl) based on renaming of the original
 command. The classical solution are object wrappers for "legacy
 components", which are more a programming than a generic approach,
 and are difficult when the "legacy component" has a different
 understanding of e.g. the composite model (like tk). I have
 implemented most of my GUIs via Motif, which is some respects easier
 to integrate, since it follows the idea "every widget has an ID"
 rather than "every widget is a command" (like in tk). The latter
 leads to the "conflict" with XOTcl, which says "every Object is a
 command". OTOH, solving this conflict is quite an interesting and
 generic challenge.

CL> Then you may store informations concerning the widget, in order to
CL> be able to save it, clone it, or whatever.

CL> The composite pattern is very convenient indeed for tk widgets. I
CL> use it to make recursive Tk bindings, or to build a graphical
CL> attribute editor for all the widget tree.

 Catherine, you seem to be quite happy with your Tk integration. Can
 you post a small but complete introductory example. Do you use Tk
 features like "-command"?

 best regards
 -gustaf

CL> --
CL> Catherine Letondal -- Pasteur Institute Computing Center

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 30 Jan 2012 12:13:12 +0100

Dear All,

over the weekend, i have implemented the discussed
functionality. On object parameters, it calls now first the
value checkers/converters and then it sets finally the value
of the property over the "assign" method of the slot (if
provided). This functionality is now in git head and will be
part for the forthcoming release.

best regards
-gustaf neumann

On 26.01.12 13:54, Gustaf Neumann wrote:
> Dear Arthur,
>
> this is a known problem area, already on our todo list.
>
...