Weblog Page

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Tue, 8 Jun 2004 08:52:45 -0400

Hullo -

This is my first posting to this mailing list. I recently started playing around with XOTcl. I had been using IncrTcl for quite a while, but XOTcl has seemed to get a lot publicity in a few other mailing lists, so I decided to give it a try.

My first impression of XOTcl is very good. I'm finding myself growing very fond of how classes are defined in XOTcl and I'm loving the dynamic nature of classes and objects in general. Though I have to admit, the "instproc", "instvar", and "my" took a little getting used to and I do miss the protection levels available in IncrTcl, but only a little. Anyway, that's not the real reason I'm posting.

Has any work gone into making a TK megawidget framework with XOTcl? I spent a little time and came up with a couple of classes that make this possible. Even though this is just a prototype, I'd be very interested in getting some XOTcl'ers feed back on this.

I've attached a file called xowidget.tcl that contains the megawidget framework package and an example of using it, SearchableListbox.tcl.

This package, which I've cleverly been calling "xowidget", provides the ability to create an XOTcl object that behaves like a TK widget. It also provides Snit-like method & option delegation to the basewidget, subcomponents, and other objects. Furthermore, the method & option delegation can be multiplexed such that a method or option is propogated to multiple objects and/or tk widgets. I've tried to document how to xowidget in source file, but if something is missing or not clear, please feel free to ask me. Here is a small example of what the syntax is like.



WidgetClass LabeledButton \
   -tkwidget frame \
   -parameter { {foo bar} }
LabeledButton instproc init args {
   next
   my instvar widgetpath
   # create a label and button in the frame
   label $widgetpath.l
   button $widgetpath.b
   pack $widgetpath.l $widgetpath.b -side left

   # make the foo parameter an configurable option
   my tkoption add foo parameter -object [self]
   # add borderwidth & relief option for the basewidget
   my tkoption add frameborderwidth widgetproc \
      -object [self] -asoption borderwidth
   my tkoption add framerelief widgetproc \
      -object [self] -asoption relief
   # add option for the text on the label
   my tkoption add labeltext tkwidget \
      -widgetpath $widgetpath.l -asotion text
   # multiplex background option to the frame, label, and button
   my tkoption add background widgetproc -object [self]
   my tkoption add background tkwidget -widgetpath $widgetpath.l
   my tkoption add background tkwidget -widgetpath $widgetpath.b
   # wildcard all other options to the button
   my tkoption add * tkwidget \
      -widgetpath $widgetpath.b

   # make the foo parameter command available
   my tkcommand add foo
   # wildcard all other commands to the button
   my tkcommand add * "$widgetpath.b"
}
pack [LabeledButton .lb -labeltext Foo -text "Press me" -command doSomething]
puts [.lb configure]
.lb invoke
.lb foo "ack"



I'm very open to suggestions and comments, critical or otherwise. If there is some interest, I'd be open to enhancing this expiriment to something more.

Thanks in advance.

-- bryan

From: Michael Aram <michael_at_aram.at>
Date: Wed, 15 Jul 2015 11:53:27 +0200

Dear XOTcl/NSF community,

in order to contrain the input of certain methods to allow only objects of
a certain type/class, e.g.:

Utility proc get_object_id_from_sourced_guid {
    -sourced_guid:sourced_guid
} { ... }


we have the following code in our code base:

if {[info command ::xotcl::nonposArgs] ne ""} {
  ::xotcl::nonposArgs proc sourced_guid args {
    if {[llength $args] < 2} return
    foreach {name value} $args break
    if {![::xotcl::Object isobject $value]} {error "'$value' is not an
object"}
    if {![$value istype ::foo::bar::SourcedGuid]} {error "'$value' is not
of type SourcedGuid but [$value info class]"}
  }
  ::Serializer exportMethods {
    ::xotcl::nonposArgs proc sourced_guid
  }
}


This works with XOTcl 1.6, but we now see the following warnings when
running the code under NSF:

Warning: nsf: Could not find value checker type=sourced_guid defined on
::nx::methodParameterSlot


What is the correct way to port this to XOTcl 2.0?

Thank you for your help!
Michael

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 24 Jan 2003 18:48:38 +0200 (EET)

On Fri, 24 Jan 2003, Gustaf Neumann wrote:

>
> The caller can certainly do with the object whatever she wants.
> if these are properties needed in the creation method they
> have to be passed somehow there, or the object can be altered,
> or one can put a mechanism on top of the creation to handle this.
> I personally would not have a problem in using two different method
> names for the different cases, like
> set msg [$cmdReader getMessage]
> set msg [$cmdReader getNewMessage]
> or to use an option like in
> set msg [$cmdReader getMessage -volatile]

But that doesn't solve the issue. $cmdReader cannot create the object
itself as volatile or bound to a variable as it will then be destroyed the
minute getNewMessage returns! Or, of course it could always use uplevel
and upvar but then every method that wants to return an object that may or
may not be bound to a variable has to provide this extra functionality and
argument checking. Ie. the methods need to be concerned with what the
caller wants, and I don't believe this is necessary a good thing.

Again, I'm not saying this feature is absolutely essential, but if one
decides to add it I believe it should be done in the best possible way ;-)

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

From: Artur Trzewik <mail_at_xdobry.de>
Date: Tue, 26 Nov 2002 19:15:32 +0100

Hi!

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

The Changes from last announced Version
- code completion by XOTcl/Tcl code editing (for variables and methods names)
- configuration maps can be stored in version system. New complex
configuration browser (only with version system)
- changes in GUI for more consistence
- many small bug fixes and improvements

By implementing configuration browser I have used some
advanced techniques as event controlling (Modell-View-Controller)
and objects-database mapping for n:m relationships (with garanted object
identity and central objects cashing - mapping for ordered objects lists).

have fun with it

Artur Trzewik

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 01 Oct 2010 08:44:58 +0200

  On 01.10.10 06:50, vitick_at_gmail.com wrote:
> Dear Gustaf,
>
> What is the reason for having XOTcl 2.0 and NX at the same time?
we will make a larger announcement in the near future
explaining the background, relationships in detail.

For now: we have a large XOTcl code base, for which it is
unrealistic to switch to the new language in short time.
Both, XOTcl 2.0 and our next scripting language are fully
scripted (loaded via package require), so they are much
easier to maintain.
> In NX, method declaration is private by default where it seems to me that it is more natural for it to be public by default (since the majority method declarations will be public) and it is the private method that should be declared explicitly.
many experiences and comments from 10+ years of xotcl were
brought into the design of nx (e.g. issues about naming,
large set of base methods, experiences from bug tracking,
etc.). One experience from larger projects (more than
500.000 tcl/xotcl code, larger and changing programmer team)
is that forcing developer to declare interfaces helps to
improve comprehensibility for starters. btw, nx has a weak
form of protection, one can call protected methods via "obj
eval .....", but these should be reminders to provide a
public interface for that functionality. Furthermore, the
default protection can be changed from the scripting level.

-gustaf neumann

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Sun, 19 Mar 2006 04:57:52 -0700

Thanks for your patience with me and my ignorance. I had inferred that XOTcl was using Tcl
namespaces for storing object attributes (methods/variables/aggregations), but in my limited usage I
didn't realize that that was (legally) being used to advantage (making plain tcl commands become
xotcl methods via namespace import or the like). So far I've been assuming the only legal way to
manipulate the object was through its handle (the object command).

Given my assumption, my thought was that you could cleanly substitute Tcl's namespace mechanism with
a hash-table lookup (attribute name -> Tcl_Obj *) for finding object attributes. Since each object
would have its own table, so there's no problem with name collisions (a attribute name is scoped by
the object you access it through, i.e., each object has its own set of slots), and if an object can
only be accessed through its handle, the handle is the only thing that needs to be exposed to the
interpreter. None of the attributes would be visible to Tcl at all (Except to the extent XOTcl
exposed them. You could still have traces and whatnot, but you'd have to use the object handle to
access them). And if the objects were always accessed via a level of indirection, the raw object
handle (the true command name) is uninteresting too, so all objects be created with autonames in the
same namespace. And that this sort of an implementation (using a custom attribute lookup mechanism
instead of leveraging Tcl's) might potentially have some performance wins and/or new feature
possibilities.

But from your explanation, using Tcl namespaces to store object attributes is not just an
implementation decision, it's really part of the interface, so my approach would break XOTcl in
varied and uninteresting ways.

      Scott

Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 03/18/2006 06:52:25 PM:

> Scott Gargash schrieb:
> >
> > Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 03/18/2006 01:39:35 PM:
> > >
> > > I do not see much evidence of a speed increase when adding a layer of
> > > indirection for every object access.
> >
> > Well, for example, it might be possible to get rid of namespaces in
> > the implementation.
> >
> thinking about getting rid of namespaces is a different theme, this can
> be done as well without "strongly aliased objects".
>
> namespaces are pretty essential in tcl. every command name lookup
> works through a namespace. xotcl uses
> tcl-namespaces for methods (procs and instprocs), for variables, and for
> aggregations. certainly, this could be
> implemented differently, frequently we have to fight with namespaces,
> but the idea was to reuse concepts
> from tcl in xotcl. Using tcl-namespaces has many advantages as well:
> currently, we can rename tcl-procs
> or tcl-commands to make it methods in xotcl; or we can namespace-import
> procs/cmds from tcl as
> methods/instmethods etc. into xotcl with the standard tcl-commands.
> >
> > If the access to the object is always through the reference and the
> > true object was never visible, you might not have to create a new
> > namespace (on demand or not)
> >
> i can't follow the argument.... what ist the relationship with the
> visibility? namespaces are used for various purposes:
> methods are tcl_procs or tcl-commands and have to "live" somewhere, in
> tcl they live in namespaces.
> one can certainly implement this differently as in tcl, as for example
> using hash-tables only, but this is not
> related to visibility. btw, if you never show the real name to the
> application developer, it will be hard to create
> multiple references other than by creating an alias of the alias.
> > or ever move an existing object to make it a child of another object.
> > The parent/subobject relationship could be inferred from the alias's
> > location in the namespace, or even tracked in child/parent hash tables
> > if you wanted to support object relationships beyond a tree (DAGs),
> > but it would not be a property of the object's location. If objects
> > never moved, everything could live in the same namespace, and just
> > tracked via the object hashes.
> >
> > And is method dispatch done via a command lookup? If so, an invariant
> > method location should allow command lookup to be elided.
> >
> whatever "same namespace" means (see above). note that we have multiple
> identical method names in procs/classes,
> they can't live in the same namespace. if the nesting relationship is
> realized via the namespaces of the aliases,
> these have to be created as well since they will most likely not exist.
> This way, they namespaces are moved
> out of the xotcl objects, but introduced at different places, where they
> are more complicated to manage.
> some interactions with namespaces will be even more complicated as they
> are now: you have to
> deal with cases, where e.g. someome deletes the alias (e.g. via "rename
> myreference {}") or deletes
> the namepace, where the alias lives in.
> >
> >
> > Of course, since I'm the one who keeps asking "How do I do this?"
> > questions, I'm probably completely wrong.
> > BTW, does invocation via an alias have any overhead? I would guess
> > not as it's (seems like) a string->Tcl_Obj mapping, the same as a
> > native command lookup, but I don't know.
> >
> an "interp alias" has a certain overhead, since it is an additional
> command invocation.
> Try the following; if you increment the loop counter in the for loop to
> e.g. 1000,
> you will get a "too many nested evaluations" error. you will see, the
> last test will be
> the slowest by far.
>
> ==========================================================
> proc t {cmd {txt ""}} {
> set n 100000
> set ms [lindex [time [list time $cmd $n] 10] 0]
> puts "[format %7.4f [expr {$ms*1.0/$n}]]ms for $cmd ($txt)"
> }
>
> proc x {} {set x 1}
> interp alias {} myset {} set
> interp alias {} myx {} x
> interp alias {} myx1 {} x
>
> for {set i 1} {$i < 100} {incr i} {
> set i1 [expr {$i+1}]
> interp alias {} myx$i1 {} myx$i
> }
>
> t {set x 1} "set"
> t {myset x 1} "myset"
>
> t {x} "x"
> t {myx} "myx"
> t myx$i1 myx$i1
> ==========================================================
>
> It is however possible to implement zero-overhead aliases
> with the tcl c-api, at least in certain situations, when one does not
> care about someone else replacing commands on the fly with
> global effects. I have implemented such things by myself.
>
> best regards
> -gustaf neumann
>
>

> ForwardSourceID:NT00007E9E

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 30 Sep 2010 09:56:08 +0200

Dear Victor,

yes, this looks nice. It is premature to add it to the set
of builtins, i have not had much uses cases for this functionality.
But as you say, it can be easily scripted (see below)....
or provided as and optional package.

> This functionality is even more enhanced with mixins and
> superclasses where each chained method would be passed to a
> mixin/superclass via [next].

one could pass in the list of methods as well per-object
mixins,
which could be added before and removed after the invocation.
however, this would make invocation less elegant, and i doubt
that there are many use cases for this.

It is not fully clear what's the best way to return the results
or errors of the multiple method invocations. The small
implementation below returns a list of results of the
individual methods, and does nothing about errors.

we plan on the new web site a community space, where can
place some implementation studies like this one.

Btw., the "opposite" problem is to call a single method with
a set of argument vectors (the method is called repeatedly
with each element of the set). There is an implementation
of that in the new regression test using the tcl8.6 function
apply (similar in length to the example below).

-gustaf neumann

=================================
package require nx

nx::Object public method chain args {
   set methods [lrange $args 0 end-1]
   set arguments [lindex $args end]
   set result [list]
   foreach m $methods {
     lappend result [$m {*}$arguments]
   }
   return $result
}

Class create MyClass {
   :method a {x y z} {
     return "a $x"
   }
   :method b {x y z} {
     return "b $y"
   }
   :create m1
}

puts [::m1 chain :a :b {1 2 3}]

From: Jegan Kumar Somi Ramasamy Subramanian -X \(jsomiram - HCL at Cisco\) <jsomiram_at_cisco.com>
Date: Fri, 23 Jun 2006 16:03:14 +0530

Hi all,
 
I have few questions in debugging of XoTcl with expect/tclsh.
 
1) How can we do debugging from expect? I am not able to use edprocs in
xoTcl. I usually do "edprocs <proc name>" from expect and I will do
necessary changes without changing the actual file. Do we have any such
option in xoTcl?
 
2) Also, is there any direct way to print or get the variables defined
in a class in expect? As of now, I am creating a simple procedure in the
expect under the required class and I am retrieving the values using
that procedure by calling them with the corresponding object.
 
3) In case of TCL, while doing debugging we do some changes in the .tcl
file and we just source it in the expect prompt to get the changes. But
in case of xoTcl, I am now coming out of expect and again opening a new
one and giving a "package require <package name>" to get the updated
information. Is there any simple way to do this as I need to reset many
of my environment while doing this process?
 
 
Thanks,
Jegan.

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Tue, 06 Feb 2001 10:16:57 +0100

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.

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

G. Neumann, U. Zdun: Filters as a Language Support for Design Patterns in Object-Oriented
                          Scripting Languages, in: Proceedings of COOTS, San Diego, California, USA, May, 1999.

In my application, every Tk widget creation is wrapped in a method:

    widgets build ${frame}::widgets::panel {
        frame $path.panel
    }

where widgets is of class Object.

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

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

--
Catherine Letondal -- Pasteur Institute Computing Center

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 29 Nov 2003 23:50:36 +0100

Dear XOTcl community,

XOTcl 1.1.0 is now available from www.xotcl.org!
Below is the full announcement text!

 best regards
-gustaf neumann

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

Announcing XOTcl 1.1.0
**********************

WHAT IS XOTCL?

  XOTcl is an object-oriented extension of Tcl that was derived from
  OTcl. In short, XOTcl tries to provide a highly flexible,
  reflective, component-based, and object-oriented environment. It
  integrates language support for high level concepts which are not
  found in other languages, with reasonable performance. It prevails
  the Tcl programming style and the dynamic/introspective nature of
  the language, rather than introducing other language's styles and
  rigidness (such as C++) into Tcl.


CHANGES relative to 1.0.2 are:

  - New functionality and improvements:

     * Transitive instmixins (thanks to a suggestion of Neophytos Demetriou):
       The new version supports a tree of mixins (mixins of mixins);
       when a mixin-class X has instmixins Y registered, and X is
       registered as instmixin for a class C, the mixin classes Y are
       applied to C as well.

     * Conditional mixins (thanks to a suggestion of Neophytos Demetriou):
       mixins and instmixins can have now guards similar to filters
       that define when they should be applied

     * New composition strategy for (filter- and mixin-)guards:
       when a guard is defined more than once for the same interceptor
       the most specific guard is used, the others are overridden.

     * Creation of sub-objects via parameter:
       XOTcl's parameter method supports now a switch named "-Class"
       which can be used to create and configure sub-objects (see
       tutorial for details)

     * New predefined method: __unknown
       This method is called, whenever XOTcl references a class,
       which is not defined yet (e.g.: Class C -superclass UNKNOWNCLASS)
       This method is used for Zoran's wonderful ttrace package
       (for aolserver and tcl-Threads)

     * Improved documentation:
        - extended tutorial (Meta-Classes, Tk, ...)
        - beautified tutorial (style files, distinction between
          literals and placeholders, ...)
        - fixed hundreds of typos

     * some speed improvements


  - fixes:
 
     * New build system:
        - per default no shells are built
        - new configure switches eg. --with-xotclsh, -with-actiweb
          --with-all

     * Fixes for https in connection with some versions of IE

     * Fixed a few issues with purify and mt (many thanks to Zoran!)
 
     * Fixes for proc-scoped variable in connections with mixins

     * Fixed passing of error codes from constructors

     * various small fixes and code cleanup
       - with newer versions of autoconf
       - various fixes for stubs
       - improved build under windows
       - starkit compliance (many thanks to MichaelL_at_frogware.com)


 For more details, please consult the ChangeLog

MORE INFO
  General and more detailed information about XOTcl and its components
  can be found at http://www.xotcl.org


Best regards,

Gustaf Neumann
Uwe Zdun

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