Weblog Page

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

Hi,

in the forthcoming XOTcl release will be several new filter features ... I've
already reported on the obj-filters. Another feature we have ready are
"filter guards". A filter guard is a condition whether a filter will be
executed or not. It is registration-centric, thus you can append the
conditions to the filter registration, example:

A instfilter {filter-1 {filter-2 {[self calledclass] == "::FigureElement"}}}

that means: filter-1 will always be executed (as in 0.85) .. filter-2 only
wenn self calledclass is ::FigureElement. Of course, you can call methods
from the filter guard, filters will not be applied to these calls.

Moreover, we have info (inst)filterguard and (inst)filterguard instcommands
on Object/Class ...

I've a half-working AOP extension written in about 100 lines of code with
this feature. Pointcuts can be defined in instprocs, so that you can do
something like:

Aspect PointCutBoundsChecking
PointCutBoundsChecking appliesTo {FigureElement Point}
PointCutBoundsChecking pointcut setXs {
  [[self] calls "Point" "setX"] ||
  [[self] calls "FigureElement "setXY"]
}
PointCutBoundsChecking before setXs {x} {
  if {$x < 100 || $x > 1000} {
    error "out of bounds x=$x"
  }
}


I hope to have a first version with the next XOTcl release ...

--Uwe

On Sunday 23 September 2001 12:08 pm, Catherine Letondal wrote:
> Hi,
>
> I guess there are interesting applications of XOtcl filters and
> mixins to aspect oriented programming? Are there any
> publications or work on this subject?
>
> Thanks,

-- 
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: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 6 May 2002 11:21:48 +0200

On Monday 06 May 2002 11:16, Zoran Vasiljevic wrote:
> int
> XOTclSelfDispatchCmd(ClientData cd, Tcl_Interp *in, int objc, Tcl_Obj
> *CONST objv[]) { XOTclObject *self;
> int result;
>
> if ((self = GetSelfObj(in))) {
> result = callMethod((ClientData)self, in, objv[1], objc, objv+2, 0);
> } else {
> result = TCL_ERROR;
> panic("Self Dispatch: could not resolve self"); /** Urks !? **/
> }
> return result;
> }
>
>
> Do we need to trigger panic (i.e. crash program) when self cannot be
> resolved ? Or is is sufficient just to return error ?

 good question. Error should be enough, esp. for people running
 servers and sourcing xotcl files.... If i do not find after
 some deeper examination a reason against, we will change this.

 thanks
 -gustaf
>
> Cheer's
> Zoran
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Sat, 2 Apr 2005 22:25:48 -0500

Hi Gustaf,

Is there a safe interp for xotcl, or does xotcl work with the safe
interp in Tcl?

Thanks,

Ben

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 25 Jan 2003 00:17:59 +0200 (EET)

On Fri, 24 Jan 2003, Gustaf Neumann wrote:

> =====================
> where one can use it like:
> =====================
> Client instproc read {} {
> my instvar reader
> my objectref msg
> set msg [$reader getMessage]
> }
> ====================
> or combined to what the tie did before... this leads to some variable-declarations,
> where we could also define parameters as references....

I think that would work very nicely with [tie]. I'm not sure about object
reference counts, though. While the object destruction with [tie] can
be thought of as a link to a variable (ie. the variable could be declared
to do that) but I see auto-destruction of an object when refs are lost
to be an attribute of the object, not of the variable which it is assigned
to. I mean, with ref counting, that variable could easily disappear, but
the object would still exist if there are references.

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

From: Jeff Hobbs <jeffh_at_activestate.com>
Date: Tue, 24 Aug 2010 13:29:15 -0700

On 24/08/2010 1:07 PM, Victor Mayevski wrote:
> Any hints about a stable release of XOTcl 2.0/Next 1.0? Date? Inclusion with ActiveTcl?

On the latter, that happens when Gustaf lets us know it's ready.

Jeff

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Thu, 20 Dec 2001 18:08:11 +0100

My first explanation for this behavior from Monday was wrong ...
sorry for that.
In fact, the filter would filter maa ... if it is called directly (try
  
  a maa

at the end of the program.) The reason why it is not filtered is that an
active filter does not filter calls issued by itself ... a filter is active
in its pre- and post part, but not during next, and only for the current
object. That is, if the filter does call a method on the same object, this
method call will not be filtered by that filter. If there wouldn't be such a
protection, there would nearly always be endless loops during filter calls
that call other methods. (Because the called filter would then issue another
call to be filtered and so on and so forth). A solution for the problem below
would be to provide two filters that do not mutually exclude each other, like:

A instproc af args {
  set method [self calledproc]
  if {[[self] exists delegate]} {
    set del [[self] set delegate]
    if {$method != "ma"} {
      return [eval $del $method $args]
    }
  }
  next
}
A instproc bf args {
  set method [self calledproc]
  if {[[self] exists delegate]} {
    set del [[self] set delegate]
    if {$method == "maa"} {
      return [eval $del mbb]
    }
  }
  next
}

A instfilter {af bf}


--uwe


> > Can anyone assist me in explaining what is happening here?
> > ------------------------------------------------------------
> > #Code: Win 98 version 0.91; got same problem with ver 0.85 3 months ago.
> >
> > Class A -parameter {delegate}
> >
> > A instproc af args {
> > set method [self calledproc]
> > if {[[self] exists delegate]} {
> > set del [[self] set delegate]
> > if {$method == "maa"} {
> > return [eval $del mbb]
> > }
> > if {$method != "ma"} {
> > return [eval $del $method $args]
> > }
> > }
> > next
> > }
> >
> > A instfilter {af}
> >
> > A instproc ma args {
> > puts "method ma of A"
> > }
> >
> >
> > Class B
> > B instproc bf args {
> > set sender [self callingobject]
> > set method [self calledproc]
> > puts "method is: $method"
> > if {$method == "mb"} {
> >
> > return [eval $sender maa]
> > }
> > next
> > }
> >
> > B instfilter bf
> >
> > B instproc mb args {
> > puts "method mb of B"
> > }
> >
> > B instproc mbb args {
> > puts "method mbb of B"
> > }
> >
> > B b
> > A a
> > a delegate b
> > #a ma ; #works ok
> > a mb
> >
> >
> >
> > _______________________________________________
> > Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
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: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 02 Jan 2008 10:28:27 +0100

Hi XOTclers,

some of you might be interested in the new release of Tloona (1.2)
providing now
support for XOTcl, ... and among many other things .. starkits.
Sounds great, and looks great

http://sourceforge.net/project/screenshots.php?group_id=190798

Details on: http://tloona.sourceforge.net/

Many thanks to Eckhard

-gustaf neumann

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Mon, 1 Dec 2003 11:02:02 -0800

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

Am I to understand this means that xotcl from CVS (or source)
now builds in a somewhat TEA-compatible fashion?
        ./configure --with-tcl=...
        make
        make test
        make install
and nothing but a stubs-based $tcl_library/../xotcl1.1/* is
installed (perhaps with docs and demos somewhere)?

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 26 Sep 2005 22:25:58 +0300

On 26 Sep 2005, at 20:40, 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

First, I want to say I'm very excited about this TIP. If this goes
into 8.5 I'd really like to see a big concentrated effort to get Tcl
back on the map. Even Ruby is getting more press than Tcl right now
and this needs to be changed. If Tcl includes an OO infrastructure
with it then that might help with the push. It is essential we do not
do this in a manner that says, "Me too", but to display the diversity
and the elegance and power of Tcl. Tcl is a command-oriented language
(instead of object-oriented), but that simple principle offers us
ways to extend it in all kinds of directions. When a new paradigm
appears, Tcl will be able to handle it too.

This is not Tcl going OO after many years of dilly-dallying, but
providing a sound foundation which supports a wide range of
extensions that have already existed. It's about making coders' lives
easier.

I do have some comments on the TIP (no surprises there):


* The description about filters at the top of the TIP is not
necessarily totally in line with XOTcl. Filters are not only about
deciding whether a method is called but can also manipulate the
message which is being passed. They can catch and do anything really.


* Mixins in XOTcl are classes which are dynamically mixed into the
normal object inheritance chain. The mixins based on the TIP seem to
be about mixing in procedures, which would be quite different.


* I disagree with the need for exported/non-exported methods. It adds
complexity and for what? How is method lookup solved? Can sub-classes
access non-exported methods? If not, wont that lead to problems for
extensions? If they are seen, can they be overridden, even by
accident, with public methods? Basically I see the whole business of
private/public as mostly a documentation issue. There could be a
mechanism in place for auto-generating docs on certain methods but
not on others, but with no actual separation between the two. I
believe Python follows this model to some extent. Convention versus
forcing.

Besides, any mechanism such as the one described can be implemented
by the use of filters. Filters offer much greater flexibility in this
respect and finer granularity. I've never actually felt the need for
public/protected/private/package.


* It is not true that XOTcl's creation mechanism makes it difficult
to do Tk-like option handling.

The -dash arguments (or methods) are called before the constructor.
The standard XOTcl way to do Tk-like options is to make the options
into so-called parameters. Parameters are basically instance
variables which have setter/getter methods attached to them. This
leads to Tk-like option handling:

Class Car -parameter {
     {doors 5}
}

set myCar [Car new -doors 3]


* I disagree with not making constructors methods. This is something
I find to be a nuisance in Java. They act a bit like methods but
aren't really methods. So I can't use normal inheritance rules to
automatically get a constructor from a super-class. This is
especially annoying with Exceptions which are often nothing more than
a new classification and have no added functionality whatsoever. It
also means a completely new mechanism needs to be in place for
constructor introspection and manipulation. In XOTcl this is trivial
as the constructor is a method like anything else.

Objective C uses the init method as a constructor (by convention) and
does not cause problems. I've never heard of anyone trying to call
[init] on an XOTcl object again. It all sounds a bit like a case of
premature protection --- something which often bothers me. Protection
makes a system more complex and often is not really needed.
Protection hasn't ever been a theme in Tcl. Let the user and
developer decide.


* Destructors. Same thing. Why? Why have something which adds
complexity when a method can manage the same? With methods the
implementation can decide whether to use the destructors further up
(there might be cases when this is not desired), or in what order to
apply its own cleanup and super-class cleanup.

I do agree that a [destroy] command might be a good idea. In fact,
I'd go the whole way and stick it on the top level. I know [rename]
can manage the same, but it's not totally obvious and then we'd have
one mechanism that does the same for anything. Oh, and whatever the
destructor does, I do believe it should not be allowed to prevent
destruction of the object (unless the [destroy] command is manipulated).


* I agree with the class vs object method naming convention.


* Having instprocs named methods sounds like a good idea.


* What about child objects? XOTcl provides a mechanism where an
object can be created as a child of another. If the parent object is
destroyed, the child is automatically destroyed too. This is often
useful and provides an alternative for one common area helped by
garbage collection (as long as these child objects are never used
anywhere else).



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

From: Vinod Kurup <vinod_at_kurup.com>
Date: Fri, 21 Jul 2006 11:03:40 -0400

On 7/21/06, Kristoffer Lawson <setok_at_fishpool.com> wrote:
>
>
> On 20 Jul 2006, at 23:58, Ben Thomasson wrote:
>
> > Hello all,
> >
> > Please that a look at http://xotcllib.sourceforge.net and reply
> > with comments or critiques. XOTclLib is a library of debugging,
> > logging, profiling, documentation, tracing, serialization, and unit-
> > testing utilities.
> > The documentation for the project is still in progress and will
> > improve over time.
>
> I tried to access this URL but it didn't seem to work. I just got an
> empty page.


Yes, it works in Firefox, but not in IE.

You have closed your <title> tag with </head>. Change it to </title> and
you'll be back in business :)

Vinod

-- 
Vinod Kurup, MD
vinod_at_kurup.com
http://kurup.org