Weblog Page

From: Eckhard Lehmann <eckhardnospam_at_gmx.de>
Date: Tue, 01 Jan 2008 13:33:54 +0100

Happy New Year!

> > I know there are filters, but I am looking for an easier way to
[..]

> Why not use filters with filterguards? I would've thought that would
> be the exact mechanism required.

Yes, it would be possible to do it that way, but it is very complicated:
- Register a filter that is by default applied to _all_ instprocs
- restrict the appliance of this filter via a filterguard

Sounds like "shooting from behind through the brest into the eye". Why not simply add/remove execution of code to particular methods, like with [trace]? There is already a [trace] method for XOTcl objects, but just for variables (at least from the documentation)...
Especially I look for a way to execute a proc before *every* statement inside an instproc. [trace] can do this via the "enterstep" and "leavestep" operators to [trace add execution]. Is this possible with filters and filterguards?


Thanks,
Eckhard

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=10

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Mon, 17 May 2004 17:02:44 +0200

Hi Adam,

I agree that mixinappend is not always the best choice; I had this
problem once
in one of my projects as well. I remember that I once wanted to
introduce {inst}[mixin|filter]prepend, but obviously haven't done it ... to
introduce the following in the next XOTcl version should be no problem,
I think:

::xotcl::Object instproc filterprepend f {
  ::xotcl::my filter [concat $f [::xotcl::my info filter -guards]]
}
::xotcl::Object instproc mixinprepend m {
  ::xotcl::my mixin [concat $m [::xotcl::my info mixin]]
}
::xotcl::Class instproc instfilterprepend f {
  ::xotcl::my instfilter [concat $f [::xotcl::my info instfilter -guards]]
}
::xotcl::Class instproc instmixinprepend m {
  ::xotcl::my instmixin [concat $m [::xotcl::my info instmixin]]
}
 
--uwe



Adam Turoff wrote:

>Hi,
>
>I'm a long-time Perl programmer who recently started using
>XOTcl on a new
>project. Support for mixins has been a tremendous boon for
>productivity
>on this project.
>
>However, the standard idioms for managing mixins (mixin and
>mixinappend) both
>feel a little broken. For example, with "obj mixin
>list_of_classes", I need
>to know the full set of mixins for an object (or a class)
>each time I mutate it.
>Using mixinappend helps, but appending new classes to the
>end of the mixin
>list seems wrong, because the newly added classes will be
>found *last*.
>
>Here is why I think these idioms don't work well: in most
>other languages, an
>object is created through successive refinement. In
>C++/Java, we start with a
>base class and derive more and more specific variants on
>that definition through
>subclassing. I use XSLT a lot, and in XSLT, the most
>specific templates are
>found after templates of lesser specificity. Surely there
>are other examples;
>these are just the first two that come to my mind. The
>underlying idiom seems
>universal, at least to me.
>
>To remedy this, I've added this primitive into my system.
>Suggestions for better
>names greatfully appreciated:
>
> Object instproc insert_mixin {mixin_list} {
> my mixin [append mixin_list " " [my info mixin]]
> }
>
>With this new operation, I can now derive an object through
>mixins in a very
>natural manner:
>
> Car mycar
> mycar insert_mixin Volkswagen
> mycar insert_mixin NewBeetle
> mycar insert_mixin AutomaticTransmission
> mycar insert_mixin Turbo
> mycar insert_mixin WasabiGreen
> ....
>
>If I were to start calling methods like "max_rpm",
>"engine_size", "color",
>or "transmission", they can all get intercepted at the right
>point in the
>mixin chain, wrapping/superceding more generic methods.
>Instant separation
>of concerns. ;-)
>
>Additionally, I can dynamically refine my object:
>
> if {$add_roof_rack} {
> mycar insert_mixin RoofRack
> }
>
> if {$has_sunroof} {
> mycar insert_mixin SunRoof
> }
>
>
>Thanks for the excellent programming environment. Hope this
>helps,
>
>-- Adam
>
>
>
>_______________________________________________
>Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
>http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
>

From: Will Duquette <will_at_wjduquette.com>
Date: Mon, 26 Sep 2005 17:05:02 -0700

On Sep 26, 2005, at 1:36 PM, Kristoffer Lawson wrote:

>> Jeff Hobbs wrote:
>>
>>
>>> 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:
>>>
>>>
>>
>> I feel slightly uneasy that debate about this TIP is occurring
>> here and on the wiki, and yet notification of its existence hasn't
>> even reached tcl-core yet. I have written some fairly substantial
>> notes on the TIP at http://www.cs.nott.ac.uk/~nem/newoo.txt .
>> These notes were supposed to be a post to tcl-core, but I don't
>> want to further pre-empt the TIP publication.

> Read through these commands. I probably agree on some points and
> disagree on others. I agree that the rationale behind [define] is
> fuzzy. I find the XOTcl model OK in that respect, but I don't have
> anything much against the TIP proposal either, and I do think it is
> a neat way of adding many methods in one go. Having syntax which
> attaches them to one another.

The point of [define] is simply that we want to be able to
create objects which have a limited set of subcommands. Note
that there's a distinct difference between writing an OO-API
using a particular OO-framework for other users of that
framework, and writing an object-style API for general users,
many of whom might not care about the OO-framework at all.
In the first case, you want to include all of the OO-framework's
bells and whistles, because you expect your users to want to
take advantage of them. In the latter case, you want to keep
the API simple, clean, and easily documented.

[define] lets us do both. With [define] "instproc" and its
siblings aren't subcommands of our objects--but at the same time,
"instproc" and its siblings are available to every user who
cares about them.

It's really an aesthetic issue rather than a technical
issue; I find many OO APIs to be terribly cluttered (Java,
I'm looking at *you*) such that it becomes hard to tell
which methods are important amid all of the ones which
are only occasionally of interest.

Will

-------------------------------------------------------------
        will -at- wjduquette.com | Catch our weblog,
http://foothills.wjduquette.com | The View from the Foothills

From: Alexandre Dehne <dehneg_at_labri.fr>
Date: Wed, 31 Mar 2004 19:35:07 +0200

Hello,

In order to use biok, I have to install xotcl. My problem with xotcl
installation is that my system is under Fedora and there is no tclInt.h
file under this distribution (even with the tcl-devel package). Of
course, I can uninstall the tcl package and install tcl manually but, by
uninstalling tcl package, other packages are going out and that put me
in trouble ...

 Any suggestion on the way to manage my tclInt.h problem ?
 Does anyone have an rpm for fedora ?

Thanks in advance
Alexandre

From: Jeff Hobbs <jeffh_at_activestate.com>
Date: Tue, 14 Aug 2007 11:13:44 -0700

Gustaf Neumann wrote:
> Major changes relative to 1.5.4 are:
        ...
> + provided compatibility with Tcl 8.5
> (currently, this requires the verison of Tcl 8.5
> from CVS head, including the changes for VarReform

 From what I understand of the patches, this is all done for
source-level compatibility. IOW, you compile with 8.4, it works with
only 8.4. You compile with 8.5, it works only with 8.5.

This represents a problem for distro developers (such as myself) because
we base our extension compiling on 8.4. The ActiveState teapot is
populated with 8.4-built extensions, all working on the assumption that
stubs is our friend.

I know that some extensions poke deeper (especially OO ones), but we
were able to maintain binary compat with itcl. Even if it is only a
special compile-time option, I'd like to encourage looking for a binary
compat (stubs supported) solution, as it will make it easier for the
transition users that will be more prevalent as 8.5 stabilizes.

Jeff

From: Adam Turoff <aturoff_at_bna.com>
Date: Mon, 17 May 2004 09:44:41 -0400

Hi,

I'm a long-time Perl programmer who recently started using
XOTcl on a new
project. Support for mixins has been a tremendous boon for
productivity
on this project.

However, the standard idioms for managing mixins (mixin and
mixinappend) both
feel a little broken. For example, with "obj mixin
list_of_classes", I need
to know the full set of mixins for an object (or a class)
each time I mutate it.
Using mixinappend helps, but appending new classes to the
end of the mixin
list seems wrong, because the newly added classes will be
found *last*.

Here is why I think these idioms don't work well: in most
other languages, an
object is created through successive refinement. In
C++/Java, we start with a
base class and derive more and more specific variants on
that definition through
subclassing. I use XSLT a lot, and in XSLT, the most
specific templates are
found after templates of lesser specificity. Surely there
are other examples;
these are just the first two that come to my mind. The
underlying idiom seems
universal, at least to me.

To remedy this, I've added this primitive into my system.
Suggestions for better
names greatfully appreciated:

      Object instproc insert_mixin {mixin_list} {
         my mixin [append mixin_list " " [my info mixin]]
      }

With this new operation, I can now derive an object through
mixins in a very
natural manner:

      Car mycar
      mycar insert_mixin Volkswagen
      mycar insert_mixin NewBeetle
      mycar insert_mixin AutomaticTransmission
      mycar insert_mixin Turbo
      mycar insert_mixin WasabiGreen
      ....

If I were to start calling methods like "max_rpm",
"engine_size", "color",
or "transmission", they can all get intercepted at the right
point in the
mixin chain, wrapping/superceding more generic methods.
Instant separation
of concerns. ;-)

Additionally, I can dynamically refine my object:

      if {$add_roof_rack} {
            mycar insert_mixin RoofRack
      }

      if {$has_sunroof} {
            mycar insert_mixin SunRoof
      }


Thanks for the excellent programming environment. Hope this
helps,

-- Adam

From: Artur Trzewik <mail_at_xdobry.de>
Date: Mon, 10 Jan 2011 22:26:27 +0100

  I suppose effect by redefining class

namespace import xotcl::*
# file 1
Class F1
F1 instproc foo {} {
     puts foo
}
# file 2 source file1
Class F2 -superclass F1
# file 3 source file 1
Class F1
F1 instproc foo {} {
     puts foo
}
Class F3 -superclass F1
F2 create f2
f2 foo
# F1 is not more superclass of F2
F2 superclass


Redefining F1 (double source) delete old implementation of F1 and so
superclass of F2.

The same as

namespace import xotcl::*
Class F1
F1 instproc foo {} {
     puts foo
}
Class F2 -superclass F1
F2 create f2
f2 foo
F1 destroy
f2 foo

Artur

> Hello,
>
> I attach a few files that will demonstrate the problem. Just run
> tester.tcl
> On my PC the effect is that I get an error message:
>
> ::tmp1: unable to dispatch method 'testA'
> while executing
> "tmp1 testA"
>
> The problem is that tmp1 is of class B and should be able to call
> testA, which is defined its superclass - A.
>
> I have found that the problem is source command, which includes file
> a.xotcl several times in several different files. I don't understand
> however why the message from interpreter says that it cannot find proc
> testA - this doesn't make sense.
>
> Is there a "nice" method to avoid this? Like in C we use #define and
> #ifndef
>
>
> _______________________________________________
> 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: Fri, 03 Feb 2006 11:40:00 +0100

Jeff Hobbs schrieb:
> Gustaf Neumann wrote:
>
>> 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.
>>
>
> Some work to enable? The general deletion of a Tcl interpreter
> will call any associated deletion callback for AssocData and
> commands. The one exception is for the last interpreter in a
> "common" shell environment, which doesn't get deleted normally
> (unless exit is undefined or you compile with -DPURIFY).
>
i am quite satisfied with the current behavior of tcl. we have various
compile
flags already in xotcl to control the behavior, mostly for debugging
memory leaks etc.
(not unisimilar to the -DPURIFY motivation in Tcl core). And yes, we are
treating
"interp exit" and "last interp exist" differently internally.

>> 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 graceful deallocation argument is mostly spurious, as the OS
> cleans things up on program exit, but freeing of external
> resources is important.
exactly.
> This is why I'm considering fixing that
> "last interp" exception above.
>
i am not sure that this would simplify the xotcl exit behavior
significantly.
The biggest problem was to get the deletion order within a namespace
correct. since objects and classes are cmds in a namespace's has table,
standard tcl deletion does not care about the deletion order. xotcl
has to care about this: if we have for example in a namespace

   Class A
   Class B -superclass A
   B create b1

we have to destroy first object b1 (since this will call the destructor
methods of Class B and A as well), and then the classes A and B.
This is slightly more complicated with nested namespaces.
Therefore xotcl has to create a topological order from the set of
destroy candidates, call the destructors in this order and delete the
c-structures in a second round. Btw, a similar topological order is
used by the serializer.


best regards
-gustaf

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 21 May 2004 20:08:37 +0200

On Wednesday 19 May 2004 17:03, Adam Turoff wrote:
> > what do you people think about the following "interceptor"
> > method: it is more verbous, but much more powerful as
> >
>
> Hm...
>
> One minor niggle is the use of the term 'interceptor'. The
> term is quite overloaded. First, this instproc manages two kinds of
> 'interceptor' interfaces for an object: mixins and filters. Second, the
> proc itself is an interceptor -- it traps calls to manage the mixin and
> filter lists. Third, as you have written this proc, it manages
> both mixins and filters, which makes them appear more similar than they
> really are.

 what you said is certainly true. I have suggested the term with a
 mindset that these two are "additional kind of interceptors normally
 not supported by other languages" (similiar to the section "Message
 Interception Techniques" in the tutorial).

 Your concern seems to be mostly the "name" interceptor.
 The commands have to do with what's sometimes is called
 "write introspection" in analogy to "read introspection", where
 you query some properties and relations of created artefacts.
 The former lets you change some properties/relations.

 The normal xotcl interface to (stack-independet) introspection
 is the info command. The pattern to change things is
  
    set old [X info PROPERTY]
    X PROPERTY [modify $old]
 
 where property is for example mixin, instmixin, filter, instfilter.
 The same pattern works with some more properties
 such as "superclass", or to some extend "class"
 as well. Some of the read-introspectable tcl properties
 such as [info body ...] or [info args] or [info default]
 could be made writable as well, but the benefit
 compared to a proc command would be relative small.

 I am not a big friend of magic variables as base
 mechanism, since otcl did not let me allow to use
 "class" or "proc" as names of instance variables.
 Methods are better since they can be easily refined.
  
 Look at the following study; it does not have the
 switch ugliness with different arglists, it is
 extensible and interceptible:

   Object introspection
   introspection proc get {obj prop} {$obj info $prop}
   introspection proc set {obj prop value} {$obj $prop $value}
   introspection proc add {obj prop value {pos 0}} {
      $obj $prop [linsert [$obj info $prop] $pos $value]
   }
   introspection proc delete {obj prop value} {
      set old [$obj info $prop]
      set p [lsearch -glob $old $value]
      if {$p>-1} {$obj $prop [lreplace $old $p $p]} else {
          error "$value is not a $prop of $obj ($old)"
      }
  }
  introspection proc unknown {m args} {
    puts "method '$m' unknown for [self]"
    puts " valid commands are: {[lsort [my info procs]]}"
  }

we can define a filter to see the consequences of
our doings:

  introspection proc i-filter {obj args} {
    set r [next]
    if {[string compare $args ""] && [my isobject $obj]} {
        set prop [lindex $args 0]
        puts "$prop of $obj = [$obj info $prop]"
    }
    return $r
  }
  introspection filter i-filter

now we can try it out:

   Object o1
   introspection add o1 mixin A
   introspection add o1 mixin B
   introspection add o1 mixin C end
   introspection delete o1 mixin *A
   introspection delete o1 mixin *A

well, we can shuffle the arguments in a little
reflector instproc:

  Object instproc introspection {cmd prop args} {
      eval introspection $cmd [self] $prop $args
  }
  o1 introspection add mixin A

and we have an "... introspection get ..." and friends again
and get an error message for a

   o1 introspection cancel mixin A

.... but: i am not so happy about the name
"introspection" in "introspection set" and
"introspection add" as well, since it requires
familiarity with "write introspection" which is
not only a "*spection" in the sense of
"looking into", but destructive.

suggestions?
-gustaf neumann

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 03 Jul 2007 20:08:07 +0200

Dear Nico,

Nico L'INSALATA (UniPI) schrieb:
> I need some clarifications regarding the use of Class parameters and
> Class slots (I will refer to v.1.5.2 of the XOTcl tutorial).
> Parameters are used throughout the introduction of the tutorial to model
> Class attributes, then slots are introduced in a later section. Are
> slots and parameters actually the same thing? Is there some reason to
> prefer one over the other?
>
historically in xotcl, parameter predate slots. since xotcl 1.5.0, all
parameters are
implemented as slots. slots are more powerful, parameters are sometimes
more
more handy to use.
> Anyway, I've started using slots and I got lost using the -initcmd feature.
> This is a "simplified" version of the code that "doesn't work" (i.e.
> I'm not able to make it work :-) )
>
> Class my_class \
> -slots {
> Attribute one -type integer -default { 0 }
> Attribute two -type integer -default { 0 }
> Attribute three -type integer -initcmd {
> if { [my one] > [my two]} {
> set _ 100
> } else {
> set _ 101010
> }
> }
> }
>
> The code doesn't work (of course!!) since [self] within initcmd has
> value "::my_class::slot::three".
yes, this is exactly the probem. slots are manager objects for managing
other objects instance variables. but maybe the initcmd should be evaluated
in the scope of the object...
> So, the question is: how do I refer to
> other attributes of the same class from within -initcmd { }?
>
i would not recommend to follow the approach sketched above.
in general, you have no control over the order in which the instance
variables are instantiated. therefore, the slot definitions are not
a valid instrument for defining attributes based on the values of other
attributes. use the constructor method (init) for such purposes

Class my_class -slots {
  Attribute one -type integer -default { 0 }
  Attribute two -type integer -default { 0 }
  Attribute three -type integer
}
my_class instproc init {} {
  my three [expr {[my one] > [my two] ? 100 : 101010}]
}

> And secondarily, is it possible to associate -initcmd with an instproc
> of the class in which the attribute is being defined? e.g. an instproc
> of Class my_class
>
this is a very sensible request independent from the attribute dependencies
above. Replace in predefined.xotcl the two methods __default_from_cmd
and __value_from_cmd as shown below, and the [self] in initcmd
will point to the object. One test of the regression test will change its
results, but you can safely ignore this.

Unless i learn from experience that the change below is not a good
idea, this modification will go into the next release of xotcl. There
will be a bug-fix release 1.5.4 before the next major release comes
out with much higher orthogonality and more slot features.

-gustaf neumann


::xotcl::Attribute instproc __default_from_cmd {obj cmd var sub op} {
  #puts "GETVAR [self proc] obj=$obj cmd=$cmd, var=$var, op=$op"
  $obj trace remove variable $var $op [list [self] [self proc] $obj $cmd]
  $obj set $var [$obj eval $cmd]
}
::xotcl::Attribute instproc __value_from_cmd {obj cmd var sub op} {
  #puts "GETVAR [self proc] obj=$obj cmd=$cmd, var=$var, op=$op"
  $obj set $var [$obj eval $cmd]
}