Weblog Page

From: Shishir Ramam <sramam_at_gmail.com>
Date: Tue, 6 Nov 2007 10:53:02 -0800

Hi,
I have a need to represent a directed graph in XoTcl.

'-childof' functionality seems to work well to represent trees.
Unless I misunderstand, it seems this will force an class-object to belong
to a single parent (1-to-many relationship).
Is there a way to represent multiple parents (many-to-many relationship)
without making multiple copies of nodes along the way?

Any help is appreciated.

thanks,
-shishir

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 07 Jan 2009 14:45:22 +0100

Dear Ben,

i do agree with you, that the default unknown handler for
classes/metaclasses is harmful. i prefer as well the explicit
create/new statement for various reasons.

The handler is a heritage from OTcl, and the reason XOTcl
keeps the heritiage is backward compatibility. Many programs
simply use unknown....

However, maybe we should mark its usage as deprecated and
remove it in future versions, such as XOTcl 2.0....

best regards
-gustaf neumann

Ben Thomasson schrieb:
> Hi XOTcl developers,
>
> I have been using XOTcl for a while and I have discovered that the
> default implementation of the Class unknown method is harmful to large
> scale development. The default implementation calls create from the
> unknown method. Here is an example that shows the problem:
>
> Class A
>
> A nstproc doX {} { puts done}
>
> A intsproc doY {} { puts done }
>
> The problem here is that misspellings of class methods will cause
> objects to be created instead of methods to be defined on the class.
> Here we will have an object named ::nstproc and one named ::intsproc
> which are both misspellings of instproc.
>
> There is a simple fix for this:
>
> Class proc unknown { args } {
>
> error "[ self ] Unknown command: \"$args\""
>
> }
>
> Class instproc unknown { args } {
>
> error "[ self ] Unknown command: \"$args\""
>
> }
>
> This will require classes and objects to be created explicitly with
> the create or new method. I find this preferable to having mistakes
> silently ignored. I have seen this problem in the wild as well as
> in my code. XOTclIDE had several misspellings that were ignored
> until I loaded with my fix. Of course existing XOTcl projects
> will have to be modified to insert create methods where needed.
>
> Ben Thomasson
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Thu, 7 Sep 2006 13:55:11 -0600

Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 09/07/2006 10:24:35 AM:

> Scott Gargash schrieb:
> > Thanks, but in my particular case I don't have knowledge of Derived,
> > only Base. By that, I mean I'm actually adding BaseMixin (the HW
> > simulator) to Base (the HW) before Derived has even been created. I'd

> > like for Derived to remain ignorant of BaseMixin because BaseMixin
> > only exists for testing purposes. I prefer to avoid having code paths

> > that exist only for testing purposes. (Which mixins are particualrly
> > well-suited for).
> well, that are your requirements, but for others it might be different.

Agreed. Except I don't understand the scenario where the current behavior
is desirable.

If mixins intercepted at the class they were mixed into, then you have the
ability to choose precisely where you want the mixin to intercept:

That could be globally by adding the mixin at the head:
::Derived mixin add ::BaseMixin ==> ::BaseMixin ::Derived ::Base

Or at an intermediate location by adding the mixin lower in the stack
::Base mixin add ::BaseMixin ==> ::Derived ::BaseMixin ::Base

But the current definition only allows for the first case, irrespective of
where the developer places the mixin. I can understand why someone might
want to intercept Derived, but if that's what they want they should have
to be explicit about it, no? Implicitly intercepting classes you don't
have knowledge of seems to be asking for errors.

At least that's how I found out how this works...

> Do you have a technical reason, why you want the instmixin BaseMixin in
the
> precedence order between Base and Derived? I have developed many
> applications with mixins/instmixin, and i never had this need.

::Base ==> Class that manipulates HW device
::Derived ==> Derived class that adds application-specific methods to the
HW device.
::BaseMixin ==> HW Simulator

Since BaseMixin simulates HW that Base would actually access, BaseMixin
terminates (some) call chains (doesn't invoke 'next'). If BaseMixin is put
in front of ::Derived, this keeps those ::Derived methods from being
invoked. If BaseMixin invokes 'next', the HW is (incorrectly) accessed.
If ::Derived is made aware of BaseMixin, then there's code in the release
application dealing with BaseMixin, which won't exist in the release
application (BaseMixin simulates HW for test purposes).

I'm sure that this is the appropriate precedence order. I'm not sure that
mixins are the appropriate solution. Or rather, I was sure but since
enough people don't share my belief that this is an issue I suspect I'm
misusing it somehow.

Implementing a simulator as a mixin seemed like a good idea. The
application has no reference to the simulator (::Derived -superclass
::Base), and the test harness can mixin the simulator as necessary (::Base
mixin add ::BaseMixin) without touching the rest of the application. It
just doesn't work.

I can accept that it doesn't work the way I want, but I'm still struggling
with why it works the way it does. I don't see the advantage of always
forcing the mixin to the head of the precedence, even ahead of classes
that haven't been defined yet. My expectation was that when I added a
mixin to a particular class, I would intercept methods at the point I
added the mixin. Why is my expectation inappropriate?

 

From: Sheik Yussuff <sheik_at_carib-link.net>
Date: Sun, 8 Jul 2001 14:10:09 -0300

Just over 6 months ago,Catherine Letondal raised

the issue of implementing "simple delegation".

Professor G. Neumann replied with some code showing

how it can be done as well as suggesting that one may

use a filter to filter all methods or an instmixin

to target specific methods for delegation.

I am now learning Tcl and XOTcl (a week or so now)at the

same time and have decided to try the filter approach.

The Experiment:

1. Create a meta-class SimpleDelegation

2. add a filter sdFilter to this meta-class

3. add an instproc setDelegate

4. Create classes A and B using SimpleDelegate

5. Create class C using Class

6. A has as delegate(instvar) an object of class B;

B has as delegate an object of class C

7. A,B and C has a method "m" defined

The Problem: (Using Windows binary ver 0.85)

I extended Prof. Neumann's code to handle above

and it works.(see Code1 below)

My experiment(Code 2) works only for the following

cases(that I tested):

1. A,B and C has a method "m".

2. The instvar delegate removed from B

It does not work when I rename the method

"m" in class C to "m2".

In this case I expect an object of class B to

execute "m" but instead I get an object of class

A executing "m" instead.

I would be grateful for any pointers to resolve

this problem.

Also I want to try to implement delegation as

described by Prof. Lieberman(OOPSLA 1986 paper).

Will be grateful for any pointers on this also.

...............

Code1: Prof Neumann's code inelegantly extended

Class A -parameter delegate

A instproc handleDelegation {result} {

if {[[self] exists delegate]} {

set context [::info level -1]

#look for method in delegated object

if {[[[self] set delegate] procsearch [lindex $context 0]] != "" } {

::upvar $result y

set y [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 B -parameter delegate

B instproc handleDelegation {result} {

if {[[self] exists delegate]} {

set context [::info level -1]

#look for method in delegated object

if {[[[self] set delegate] procsearch [lindex $context 0]] != "" } {

::upvar $result y

set y [eval [[self] set delegate] $context]

return 1

}

}

return 0

}

B instproc m {x} {

if {[[self] handleDelegation r]} {

return $r

} else {

puts "[self] [self class] [self proc] $x";

return [next]

}

}

Class D

D instproc m2 {x} {

puts "[self] [self class] [self proc] $x"

next

return [expr {$x*2 + [[self] set v]}]

}

D d1

d1 set v 100

B b1 -delegate d1

A a1 -delegate b1

puts "result = [a1 m 123]"

...............................................

Code2: My Try using filters

#create SimpleDelegation as a meta-class

Class SimpleDelegation -superclass Class

SimpleDelegation instproc sdFilter args {

set method [self calledproc]

if {[[self] exists delegate]} {

set del [[self] set delegate]

#if delegate has method then dispatch it.

if {[$del procsearch $method] != ""} {

return [eval [$del $method $args]]

}

return [next];

}

}

SimpleDelegation instproc init args {

[self] filterappend [self class]::sdFilter

next

[self] instproc setDelegate {d} {

[self] set delegate $d

}

}

SimpleDelegation A -parameter delegate

SimpleDelegation B -parameter delegate



A instproc m {x} {

puts "[self] [self class] [self proc] $x"

return [next]

}

B instproc m {x} {

puts "[self] [self class] [self proc] $x"

next

return [expr {$x*2 + [[self] set v]}]

}

Class C

#method "m" renamed to "m2" here.

C instproc m2 {x} {

puts "[self] [self class] [self proc] $x"

next

return [expr {$x*3 + [[self] set v]}]

}

A a

B b

a setDelegate b

b set v 100

C c

b setDelegate c

c set v 100

puts "result = [a m 123]"

..................................................

Regards,

Sheik Yussuff

email: sheik_at_carib-link.net

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 31 Dec 2007 23:22:16 +0200

On 31 Dec 2007, at 18:14, Eckhard Lehmann wrote:

> I know there are filters, but I am looking for an easier way to
> react on execution of particular methods/procs... for a mechanism
> that works for xotcl objects the same way as [trace] works for pure
> Tcl.

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

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

From: Kristoffer Lawson <setok_at_scred.com>
Date: Thu, 5 Aug 2010 11:38:47 +0300

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

> In my understanding, Kristoffers point was that although he is using
> XOTcl since many
> years (i see postings from him more than 10 years ago) and although he
> is a experienced
> programmer, he was not aware of the problem with argument values
> starting with a dash
> (certainly not all, e.g. negative numbers are fine), and he was not
> aware of the escape
> mechanism (which was added to XOTcl early 2003, see Changelog).

Cheers, and apologies if any offense was caused by my postings. This just caught me completely off guard. Of course once I saw it, it was obvious what is happening, but it really is something you can easily miss, especially as existing XOTcl code out there will not generally worry about it.

> The primarily problem is external input, unfortunately, one weak element
> of most
> scripting languages. Similar problems lurk around in Tcl in scripts like
>
> set file1 -force
> set file2 -violence
> file delete $file1 $file2

Indeed. The slight saving grace for those cases is that, in practise, one tries to look more carefully before operating on any filenames passed by the user, but I agree it's quite easy to get caught out there too. Maybe Tcl should have used a different model for optional arguments (something like [file {delete -force} $file] perhaps?), but it's unfortunately difficult to turn back the clock on that...

> The case with the dash arguments in XOTcl is especially nasty to the
> unaware, since the standard configure method determines on the "-"
> (a) where the last argument list ends, and (b), what to call as a method.
> If user-data is passed to the object creation, using the list notation is
> therefore a must (as mentioned by Artur)

Yes, this is also true for setting a parameter:

Car new -doors $amount

If $amount contains a dash, it'll do a method call. Just something to be aware of. It's also not just for user-passed values either. The same could apply to random data, or binary data, or the contents of a file, for instance. Watch out if you're doing a YAML parser.

> People fully aware of the XOTcl flexibility have no big problem with this,
> since they can write their own "configure" method (this method
> implements the dash interpretation) and use this (e.g. via mixins)
> where appropriate.

Yes, if something positive has to be said then it is that flexibility. I went one further and already created a method directly into 'Class' ;-)

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

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Wed, 26 Sep 2001 16:24:14 +0200

On Wednesday 26 September 2001 03:46 pm, you wrote:
> Actually this is a valid point. As classes can naturally be dynamically
> added and removed, the whole AOP logic can be implemented by classes
> which are just brought into the inheritance chain, and which
> provide the required filters. In that case I cannot immediately see
> any benefit in providing the filter as a separate object.
>

There would some benefit if there is a common class "Filter" for all filters
or if you could directly manipulate the filter info that way. I'm not sure
yet how to do it the best way, but both features would be quite handy for
other XOTcl structures as well.

--Uwe

PS: another issue: there were some requests for new info options on this list.
right off the head:

- list of all procs defined for an object (procs + all instprocs up the
  heritage order)
- list of all mixins (mixins+instmixins) for an obj
- list of all filters (filters+instfilters) for an obj

Perhaps return certain infos conditionally as ligthweight objects ...

Were/are there any other suggestions?

-- 
Uwe Zdun
Institute for Computer Science, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_uni-essen.de

From: Jeff Hobbs <jeffh_at_activestate.com>
Date: Wed, 11 Oct 2006 18:21:25 -0500

Scott Gargash wrote:
> Is it possible to build XOTcl as universal/fat binary for OS X? What is
> the command line for the configure tool ?

This is all handled by TEA (yay!). It should "just work" if you set up
for building the same as you would the core universal.

Jeff

From: Salazar, German P21322 <german.salazar_at_siemens.com>
Date: Sun, 3 Dec 2006 19:57:47 -0500

Well, I have been doing some programming in tcl and after recognizing
that my second edition book is rather old, I acquired Practical
Programming in Tcl and Tk, 4th Edition. In there, within the chapter
about Namespaces, they talk about Object Systems and mentioned [incr
Tcl] and XOTcl; the latter one as a more recent development.

So, I went ahead and checked out
    http://www.tcl.tk/man/itcl3.1/index.html
and
    http://media.wu-wien.ac.at/doc/tutorial.html
 
Granted, I am not experienced in objects, although a couple of years ago
I went back to a local community college for a nice Java course where I
learned about OO and concepts like Inheritance and Encapsulation. So,
needless to say, I was able to understand itcl right away and I am
having the hardest time understanding xotcl.
 
So, I gather that xotcl seems more versatil (and hence more
powerfull?)...is [incr tcl] good enough?
[incr tcl] seems easy (to me, with my Java knowledge) to grasp and
program. How does xotcl compare?
 
I'm just having a hard time separating Objects and Classes, each with
its own definitions and methods, etc. By the way, the soccer team
example did not include anything on Objects, everything was
Classes...so, I was up for a surprise when they started to talk about
Objects in the same way they did about Classes. The following
statements hit the nail right on the head for me:
 

        "This is possible (and not senseless) because of the per-object
specialization ability and the dual shape of a class, which is at the
same time object and class. Both lead to a seamless connection of the
run-time properties (the object features) and their descriptive
properties (the class features). It is possible to avoid the strict
distinction between them, known from static typed languages, like C++,
Java, etc."

 
Needless to say, I am having a hard time with the first sentence from
the quotation above.
 
The xotcl toturial is 67 pages long, is it standalone or do I require to
know otcl before taking on xotcl?
Are there learning alternatives for xotcl other than the tutorial
mentioned above?
Are 67 pages enough? The book "[incr tcl/tk] from the Ground Up" is over
700 pages long!
 
Any advice? Do you get a lot of questions like these from newbies? Or am
I speaking to the wrong crowd i.e., you all love xotcl and think is easy
to understand?
 
Thanks for any tips.
 
G.Salazar
 

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 6 Jan 2007 13:13:15 +0200

Here is some code that worked before:

Class C -parameter {
     # doifjhfdoi: sdoifhjh
}

OK, so this 'comment' may or may not have been fully legal before,
but now it fails in a bad way:

during '::C parameter'

Ie. no actual error is given.


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