Re: [Xotcl] Improvement proposal for instfilters and guards

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 30 May 2008 14:34:53 +0200

Dear Eckhard,

Eckhard Lehmann schrieb:
> In 99% of the cases one (I at least) creates a filter that needs to be
> triggered only at a certain method.
The more efficient approach for just intercepting a single method is a
mixin. The purpose of the mixins is intercept one or more known
methods, the strength of the filters is to execpt all methods. This
can be certainly restricted by the guards, but there is a performance
penalty in such cases.
> Class A
> ...
> A instproc do1 {} ...
> A instproc do2 {} ...
> A instproc do3 {} ...
>
> A instproc do1Filter {} ...
>
> # trigger only at do1
> A instfilter do1Filter -methods do1 ;# or -methods {do1 do3}
>
well, note that "instfilter" accepts a list of filters (with potential
guards)

> # rather than
> A instfilter do1Filter
> A instfilterguard do1 {[string eq [self calledproc] do1]}
>
You can define the guard as well at the registraton of a filter, so there is
no need for two separate statements.

A instfilter {
  {do1Filter -guard {[self calledproc] eq "do1"}}
}

It should be possible to create a different front-end in tcl, to provide
more
syntactical sugar and create the guarding expression on the fly:

proc mk_guard args {
  for {set i 0} {$i < [llength $args]} {incr i} {
    if {[lindex $args $i] eq "-methods"} {
      puts stderr M
      incr i
      set clause [list]
      foreach proc_name [lindex $args $i] {
        lappend clause "\[self calledproc\] eq \"$proc_name\""
      }
      lappend guards [join $clause ||]
    }
  }
  return [join $guards &&]
}

The interceptor via mixin could be done like the following

   A instmixin [Class new -instproc do1 args {puts hi; next}]

> Is such a feature already planned? If not, is there anything that speaks
> against it?
>
the major argument against it is not to bloat the language with a subset of
its functionality.

However, can you tell more about your use-cases?

I was thinking a few times about providing interceptors
for single methods, similar to the method combinator :around
in CLOS.

http://www.aiai.ed.ac.uk/~jeff/clos-guide.html

This approach could allow to assign something
like the filter to a single method of a single class.
The advantage would be to no search and testing
to filter away the unwanted filter class, but stick
this to a method. The approach could fit nicely
into the method-slots (in the pipe for 2.0) and
could server as a generalization of the
current pre and post conditions in XOTcl.

-gustaf neumann