Weblog Page

From: Mark Strembeck <mark.strembeck_at_wu-wien.ac.at>
Date: Fri, 14 Mar 2008 16:00:37 +0100

On Friday, 14. March 2008 15:24, Luc Rasson wrote:
>
> Maybe it is not the proper mailing list but I was wondering if any
> -business- rules engine based on the RETE algorithm exists for XOTcl ? (as
> for example Drools for Java) ?
>
> If yes, all informations/links/resources are welcome :)

  As far as i know, an XOTcl implementation of the RETE algorithm does
  not yet exist. However, if you like to contribute such an implementation,
  your very welcome :)

  best regards,

  Mark

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Wed, 28 Dec 2016 13:20:14 +0100

Dear Community,

We are pleased to announce the availability of the Next Scripting
Framework (NSF) 2.1.0 as a Christmas present to the community.

Over the last years, NSF is constantly being developed based
on experience in largish projects. To document these changes
we have decided it to bump the version numbers and make
a new release.

Since the release of NSF 2.0.0, there have been more than 450
commits to our code repository. For this release NSF was
tested in 192 build configurations with Tcl 8.5.19 and
Tcl 8.6.6 on Linux and Mac OS X (both using recent gcc and
clang). Common build configurations have been tested under Windows
(Windows 2012 Server: VS15 & MSVC 19, MinGW).

Diff stats since 2.0.0:
  186 files changed, 26475 insertions(+), 15671 deletions(-)

Major changes relative to 2.0.0 are:

- Improved debugging/tracing/profiling support (NSF)
- Deprecated and debug modes for NSF procs and methods (NSF, NX, XOTcl2)
- Script-level access to NSF parameter/argument parser (NSF).
- Slot-trace reform (NX, XOTcl2)
- Updated MongoDB interface to the newest mongo-c-driver (NSF, NX)
- Improved scripted shells (e.g., nxsh, xotclsh)

Below is a summary of are the changes in more details. The detailed
changelog is available at
https://next-scripting.org/xowiki/download/file/ChangeLog-2.0.0-2.1.0.log

NSF 2.1.0 (containing NX 2.1.0 and XOTcl 2.1.0) can be obtained from
https://next-scripting.org/. Please report issues and wishes by opening
a ticket at https://sourceforge.net/p/next-scripting/tickets/.

Best regards
- Gustaf Neumann
- Stefan Sobernig

========================================================================
New Features

- NSF:

   * Improved debugging/tracing/profiling support:

     + NSF procs and methods can be marked "deprecated" and/or
       "debug-enabled". For this, all NSF proc and method definitions
       in NX and XOTcl2 now accept the new flags "-debug" and
       "-deprecated". The low-level interface (nsf::method::property)
       enables introspection and selective enabling during runtime.

           nsf::proc ... ?-debug? ?-deprecated? ... /name/ /argspec/ /body/
           nsf::method::property /obj/ /method/ deprecated ?0|1?
           nsf::method::property /obj/ /method/ debug ?0|1?

       A debug-enabled NSF proc or method will be reported on entering
       and exiting the proc and method (similar to a traced proc/
       method incl. a time probe; see above):

           % nsf::proc -debug foo {} {return 123}
                 % foo
           Debug: call(1) - foo
           Debug: exit(1) - ::nsf::procs::foo 72 usec -> 123

       The enter and exit messages can be tailored and redirected
       at the script level by redefining "::nsf::debug::call" and
       "::nsf::debug::exit", respectively.

       To actively manage API evolution, NSF procs and methods can be
       marked "deprecated". Using deprecated procs/ methods will result
       in a warning:

           % nsf::proc -deprecated foo {} {;}
           % foo
           Warning: *** proc foo is deprecated.

       The warning message can be tailored and redirected
       at the script level by redefining the proc "::nsf::deprecated".

     + NSF procs and methods can be profiled (and optionally traced)
       when profiling support is configured during compilation

          ./configure --enable-profile (default: disabled)

       This can be controlled via

          nsf::__profile_trace -enable /bool/ ?-verbose /bool/?
          nsf::__profile_get
          nsf::__profile_clear

       When profiling is enabled, the profiling data is kept in memory
       and can be obtained via "nsf::__profile_get" in form of a list
       structure containing the wall clock time since start of
       profiling, the aggregated ms and lists containing object times
       (what time was spent in which object/classes), method times
       (what time was spent in which methods) and proc data (what time
       was used in which procs) followed by trace data (showing calls
       and exits of methods/procs/cmds). When "nsf::__profile_trace" is
       called with the "-verbose" flag, the trace is printed via
       "nsf::log".

   * Add script-level access to the NSF argument parser to conveniently
     process, e.g., non-positional parameters/arguments and value
     checkers. See
     https://next-scripting.org/xowiki/docs/nx/tutorial/index1#_parameters
     for the details.

     The command

          ::nsf::parseargs /paramspec/ /arglist/

     can be used to parse arglist based on the paramspec to set the
     parsed arguments in the local context. For example, the command

              % nsf::parseargs {{-x:integer 1} y} {123}
         % set x
         1
         % set y
         123

      will define variables x holding "1" and y holding "123" for the
      current Tcl scope.

   * Minor logging reform (NsfLog, interp): "nsf::configure debugLevel
     /severity/" will print error messages at a level equal or greater
     than the given severity (0, 1, 2, 3). For example, "nsf::configure
     debugLevel 0" will print any "nsf::log" message, and
     "nsf::configure debugLevel 3" will print just "nsf::log" level 3
     (error) messages while omitting warnings etc. This does not entail
     changed logging semantics, but helped remove some confusion at the
     NSF/C level.

   * Improved NSF/C code generator (gentclAPI.tcl): Allows for
     specifying and generating enum types.

   * Misc:

     + New flag "-notrace" for "nsf::var::set" and "nsf::var::get" to
       implement ability to use these low-level commands for accessing
       variables without firing Tcl traces.

     + New cmd "nsf::method::forward::property" for reading for writing
       introspection of forwarders. This is important for the
       serializer to map the per-object forwarder when different target
       objects are specified.

     + New option for call-stack introspection: "nsf::current
       level". It returns the stack level of the currently executing
       NSF method (like "info level"), or an empty string outside of an
       NSF context.

- NX:

   * NX method definitions ("alias", "forward", and "method") now
     accept the optional flags "-deprecated" and "-debug". See NSF
     section above for usage details.

        /cls/ public alias ?-deprecated? ?-debug? /method/ ...
        /cls/ public forward ?-deprecated? ?-debug? /method/ ...
        /cls/ public method ?-deprecated? ?-debug? /method/ ...
        /obj/ public object alias ?-deprecated? ?-debug? /method/ ...
        /obj/ public object forward ?-deprecated? ?-debug? /method/ ...
        /obj/ public object method ?-deprecated? ?-debug? /method/ ...

   * Improved object and method introspection: Newly added
     introspection subcommands complete the set of introspection
     commands and reflect the newly introduced method options.

        /cls/ info method callprotection
        /cls/ info method debug
        /cls/ info method deprecated
        /obj/ info baseclass
        /obj/ info object method callprotection
        /obj/ info object method debug
        /obj/ info object method deprecated

   * Reform of traces on slot-managed object variables: Revised the
     interface and semantics for the interaction of variable traces and
     slots. It is now possible to specify in the definition of a
     "property" or "variable" whether the slot-accessor methods
     ("value=get", "value=set") should be fired whenever a variable is
     read/written or when it is initialized to a default value for the
     first time ("value=default").

        /obj/ object property|variable ?-trace set|get|default? ...
        /cls/ property|variable ?-trace set|get|default? ...
        
     See the nx::Object and nx::Class man pages for details.
     This supersedes the experimental interface available in
     XOTcl 1.* based on "initcmd", "valuecmd" and "valuechangedcmd".

   * Documentation (API and examples):

     + Added

       Rosetta implementations: Inheritance/ single, add object
       variable dynamically, tree traversal, and tokenizer.
        
     + Updated

       Object.man: Added missing description on "info lookup
       parameters" and "info lookup syntax"; corrected description of
       "copy"; added "info baseclass"

       {alias|forward|method}.man.inc: Added documentation of
       "-debug" and "-deprecated" switches.

       current.man: Added description of 'level' option.

       Rosetta implementations: Inheritance/multiple, polymorphic
       copy, multiple distinct objects

- XOTcl2:

   * XOTcl2 method definitions ("proc", "instproc", "forward", and
     "instforward") now accept the optional flags "-deprecated" and
     "-debug". See NSF section above for usage details.

         /cls/ instforward -deprecated|-debug /method/ ...
         /cls/ instproc -deprecated|-debug /method/ ...

         /obj/ forward -deprecated|-debug /method/ ...
         /obj/ proc -deprecated|-debug /method/ ...

   * New -return flag: XOTcl2 method definitions can now specify a
     return-value checker, similar to NX methods.

     /cls/ instproc -returns /method/ ...
     /obj/ proc -returns /method/ ...


- Shells:

   * There is now an improved and packaged shell implementation:
     nx::shell2. It is used by all four shell scripts. nx::shell2
     builds on Tcl's event loop, rather than while + update. This
     avoids blocking the Tk main window (update). In addition,
     nx::shell2's behavior is more akin to Tcl's native shells (e.g.,
     no extra lines on enter, catches EOF). The Tcl package can be
     conveniently sourced, e.g., in Tclkit main scripts.

   * The new shells accept script input now via stdin or as provided
     via "-c" in the command line.

   * They are more robust: Don't quit due to inner [return] calls,
      [exit] is handled gracefully.

   * Added tests for the shells to the regression test suite
     (shells.test).


- Traits:

   * The namespace "nx::traits::XXX" was renamed to "nx::trait::XXX" in
     order to improve naming orthogonality with the trait management
     package "nx::trait".

- MongoDB interface upgrade:

   * Upgraded MongoDB and drivers to mongodb-c-driver 1.5.1, libbson
     1.5.1 and MongoDB v3.4.0.

   * The upstream mongodb-c-driver has deprecated the old OP_QUERY syntax
     with $-modifiers and old names like $orderby and $query, which will
     be removed from the driver. The new interface is more in the mongodb
     style, many former parameters (e.g. -limit, -skip, -project, -sort)
     went to the new "-opts" argument.

       mongo::collection::query /collection/ /filter/ ?-opts /opts/?
       mongo::cursor::find /collection/ /filter/ ?-opts /opts/?

     See the begin of nsf-mongo.test file for examples for queries with
     the old and new interface. The high-level interface for nx::Object
     is unchanged.

   * Support for new binary type "decimal128"
   
- Maintenance & bug fixes:

   * Tcl command resolvers and command literals:

     Between Tcl 8.6.0 and (including) Tcl 8.6.6, there was a problem
     in the interaction between Tcl 8.6 and the command resolvers of
     NSF in certain corner cases and Tcl's command literals. The issue
     and patches were reported upstream to the Tcl core team, was
     recognized and will enter an upcoming patch release (8.6.7). Our
     regression test-suite was extended accordingly to track the issue.

     See Tcl Fossil tickets d4e7780ca1 and 3418547.

   * Finalizing NSF and NSF object systems:

     In this release, the finalization procedures of NSF (on process
     exits, thread exits, and interp teardowns) has been revised. For
     example, NSF's ExitHandler is guaranteed to be called just once in
     the above scenarios (e.g., to avoid double frees of NSF
     structures).

   * Fixed a long-standing and not easy reproducible bug when deleting
     classes in multiple nested diamond inheritance structures.

   * UnsetTracedVars:

     Provide for a two-pass deletion logic during object shutdown, to
     account for unset traces possibly reviving an object variable
     under deletion. This corresponds to a recent memory leak fix to
     Tcl itself. See also Tcl Fossil ticket 4dbdd9af144dbdd9af14.

   * Serializer:

     The combined NX and XOTcl2 serializer has been extended to cover
     newly added features (esp., NSF procs, method flags) and has been
     improved based on experiences from multi-threaded NSF/Tcl
     applications (NaviServer). Improvements and fixes relate to "info"
     methods and forwarders.

   * Tcl 8.7:

     Preliminary support for a future Tcl 8.7 (as of Dec 2, 2016;
     commit 71fa1f9c91). NSF compiles under 8.7a0 and its regression
     tests execute successfully.

   * Misc (esp. NSF/C):

     + Refactoring: There is now a common infrastructure for
       hash-tables using function pointers as keys (as required for
       NSF/C command definitions and enumerations).
     + Removed all implicit type-conversions, signed/unsigned
       comparisons as flagged by the following gcc/clang flags (ensure
       cleanness on 64bit) -Wconversion -Wsign-conversion
       -Wfloat-conversion -Wsign-compare.
     + Reduced variable scopes.
     + Guarded against potential Tcl_Obj leaks, esp. when using
       "NsfMethodNamePath", as indicated by valgrind.
     + Refactored functions for topological sorting ("TopoSort") to
       avoid code redundancies.
     + Addressed more than 18 code-quality issues as indicated by
       Coverity Scan, incl. control-flow issues (risking NULL
       dereferencing), dead code branches, etc.
     + Removed uses of deprecated functions, e.g. "Tcl_AppendResult".
     + Based on the improve NSF/C code generator (see above), proper
       enum types are used in generated function signatures and the
       respective control structures (switch).

   * Extended regression test suite:
     The test suite contains (for Tcl 8.6.6) now 5852 tests.

- Packaging & distribution:

   * Updated TEA to 3.10
   * Support for MSVC 1900 (VS 2015; win/makefile.vc)
   * Debian package: https://packages.qa.debian.org/n/nsf.html
   * MacPorts port: https://trac.macports.org/browser/trunk/dports/lang/nsf/Portfile
   * Part of the KitCreator battery: https://kitcreator.rkeene.org/fossil/
   * Part of the kbskit battery: https://sourceforge.net/projects/kbskit/

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 30 Dec 2003 18:19:04 +0100

On Tuesday 30 December 2003 12:25, Artur Trzewik wrote:
> Hi!
>
> I have discovered some interesting change in 1.1.1 that I could not find in
> ChangeLog.

 Artur, you discovered this change not in version 1.1.1, but in the
 pre-release of version 1.1.2, that i have sent to you a few days ago.
 The change is documented in the Changelog of 1.1.2

> In 1.1.1 one can access to subobject as method call
> Example
> b::a
> can be produced as
> b a
> My problem is that I have "a" as method and as subobject from b.

 There are several rationales for this:

   * Background:
       In general Tcl distinguishes between procs and commands,
       where the fist ones are defined in tcl and the others in C.
       If you define a proc/command, then you are overwriting
       potentially a command/proc.

       Objects and classes are commands in xotcl. Every
       Object builds a namespace (not necessarily a
       tcl-namespace) in xotcl , in which the procs, subcommands
       and subobjects of the object are stored.

       The situation in versions up to 1.1.1 was a follows

          Object o
          o proc a {} {puts "i am proc a"}
          o a ;# prints i am proc a
          Object o::a
          o a ;# error message: o: unable to dispatch method 'a'

       The created Object has overwritten the proc a, since it occupies
       slot "a" in the command table of object o. The same happens
       as well when a proc is overwriting an object, the same situation
       happens as well with other subcommands (not only procs) of
       the object.

       So the situation is quite bad, since the sub-object
       - can delete procs/commands
       - it cannot be called directly
       - it breaks in invariant: an (sub)object is a (sub)command and
         can be called exactly like it.

   There are several useful scenarios for the new behavior.
    * one can use xotcl objects to define commands with subcommands,
       where the object forms the "main command" and the procs/commands
       define the subcommands. For example one can defined a specialized
       version of Tcl's file-command (say ns::file) like in the following:

namespace eval ns {
    Object file
    file proc tail name {
        set tail [file tail $name]
        regexp {[^/\\]+$} $tail tail
        return $tail
    }
    file proc unknown {subcmd args} {
        return eval ::file $subcmd $args
    }
}
     The neat thing is that it is possible
     - to redefine sub-commands via procs (instead of a large
       and hard-to-extend switch statement)
     - to use interceptors (filters/mxins) for certain subcommands (maybe you
       are only interested in "file delete")
     - to extend command on the fly by defining new subcommands
     - to use the unknown mechanism to produce dynamic error message
       about valid subcommands.

    This was possible since a long time in XOTcl; what's new in the prerelease
    of 1.1.2 is that the same can be used now with sub-subcommands and so
    on in a uniform way. This makes it possible, for example, to use this
    mechanism for xotcl's info command as well, which is already a subcommand
    of the object/class (e.g. [Object info instances].

  * In many cases the programs become syntactically cleaner than
   before. One can also write now instead of

      Http::Wrk instproc init .... {
          ...
          [self]::connection translation binary
          ....
    the invocation of the subobject without [self] by:

        Http::Wrk instproc init .... {
          ...
          my connection translation binary
          ....

    Interesting enough, in many situations the new variant
    is faster as well (Artur, check out speedtest.xotcl of the 1.1.2 prerelease).

> Can I force "b" to invoke method "a" and not return subobject "a"?

 The calling order is mixins before instmixins before procs/cmds
 before instprocs from the classes. Therefore, the object a
 shadows in your example the instprocs, which is the problem you
 are facing.

 well, we have currently following options implemented:

   a) if you call an object by it name (without method), it returns
      the name of the object. e.g.:

          Class C
          C instproc a {} {puts instproc-a}
          C o; C o::a
          puts [o::a] ;# outputs ::o::a

      This is implemented via a method "defaultmethod",

          puts [o::a defaultmethod] ;# outputs ::o::a

      which can be redefined by the user (e.g. via proc). This method
      can call other things as needed and return finally [self].
      you can not do is to call the instproc a of class C via next (since
      the active object is alreday ::o::a).

      You can, however call from defaultmethod
      ::xotcl::classes::C::a directly, but this is not recommended, since
     you will have the "wrong" self, etc.

    b) you can define an interceptor for method a, e.g. via mixin class

    c) use different nameing conventions for sub-objects, e.g.
       C o; C o::_at_a

 Sorry for being long, but i hope this explains the rational for the change.

 best regards and all the best in the new year

-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: Wed, 27 Mar 2002 21:02:54 +0100

On Tuesday 26 March 2002 16:09, you wrote:
> Dear XOtcl list,
>
> I have some problems to install the latest xotcl version on a linux debian
> platform. The current debian package is 0.85 and I would really like to
> install 0.9.
>
> So I have tried to install the full source distribution
> (http://media.wu-wien.ac.at/download/xotcl-full-0.9.3.tar.gz), but, as
> tcl/tk debian include installation is in the same directory
> (/usr/include/tcl8.3), it's difficult to tell configure how to deal with
> it.


 dear cathrine,

 for the time being, the simplest thing is to
 add manually in xotcl-full-0.9.3/xotcl-0.9.3/unix/Makefile
 after the configure run -I/usr/include/tcl8.3 at the place
 where the other "-I"-option are written.

 that should keep you going for now
 best regards
-gustaf

>

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sat, 18 Aug 2001 08:51:29 +0200

On Tuesday 14 August 2001 04:10, you wrote:
> this is more or less what we have currently scheduled for 0.86
> used as result for [self next] and [.. procsearch ....].
> actually, having another order, such it has the same order
> as in the definition.
>
> {b foo3 proc} {B instproc foo1} {A instproc foo2}
>
> however, it would be still nicer to have methods as objects.
>
> {m1 m2 m3}
>
> [m1 class] -> Proc
> [m2 class] -> Instproc
> [m3 name] -> foo2
>
> this would allow more methods on procs/instprocs and this is
> extensible with more metadata (e.g. pre/post conditions,
> c-code vs. tcl-code -> getting rid of the distinction of instcommand vs.
> instprocs ....).
>
> Another interesting idea is to use aggregations for methods.
>
> Class C
> C proc f {} {...}
> C instproc m {} {...}
>
> would lead to
> C::f
> C::m
> where C::f amd C::m being of class Proc or Instproc
>
> one could even use
>
> Class C
> Proc C::f {} {...}
> Instproc C::m {} {....}
>
> In the most straightforward case, this would exclude having instproc and
> procs of the same name, which is not great
> (OTH, other OO languages do not allow these either)... the cool part is
> that it is very easy to find out, where the command is defined, and
> moving, renaming etc. could work with the standard move/rename etc.
> methods, and "info procs" is not much more than a specialized "info
> children"....the long list of things in "info info" can be reduce....
>
> but there are as well many arguments against it. one thing is memory
> consumption. to even think about it, we should find a way of defining
> lightweight objects....

I think it is a general problem of XOTcl. It is based on Tcl.
Tcl is string oriented. We say everything is the list (string).
Also internal interpreter interface (Tcl_Obj) is based on this principle. So
internal object can be converted to string and we can build internal objects
from string.
XOTcl objects are based on so called handlers principle.
Therefore XOTcl can not offer so complete (ger. durchgängig) language
principle. everything is an object (see Smalltalk).
That is not so tragic. I think the importest thing is to get good mix
between list and object-oriented world.

The lightweigh objects are very important for such think as interface to
other languages (C++). The possible solution (see my maligns to garbage
collection) is to make XOTcl also internal really Tcl objects.
This is hardly possible with actual Tcl interpreter.
The second thing is that XOTcl will become another incompatible to early
version language.

So I am very anxious on next development of XOTcl
"(we have a mostly working SWIG bindig for xotcl)" that will be cool

Artur Trzewik

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Wed, 09 Jun 2010 15:28:26 +0200

> The problem was that, somehow, I managed to change "-d" in -default to
> "D"... I read several times the code and I didn't see it until now.

voilà ... good to know it was a typo.

//s

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Mon, 4 Mar 2002 12:15:37 +0100

In file xotcl.c:

static int
XOTclCNewMethod(ClientData cd, Tcl_Interp* in, int objc, Tcl_Obj *objv[]) {
  XOTclClass *cl = XOTclObjectToClass(cd);
  XOTclObject *obj = &cl->object;
  Tcl_Obj *cname, *autoname;
  char *name, *n;
  int result, offset=1;
  DEFINE_NEW_TCL_OBJECTS_ON_STACK(objc+1, ov);

  /* ^^^^^^ */
   
Should read:

  DEFINE_NEW_TCL_OBJECTS_ON_STACK(objc+2, ov);

... because later in file, ov[0] and ov[1] are
reserved for internal use and other arguments
are copied over which results in trashing memory.

Cheers
Zoran

From: Matthew Smith <chedderslam_at_gmail.com>
Date: Fri, 16 May 2008 11:10:35 -0500

-PS: it makes sense to concentrate the discussion to one place, e.g. the
-OpenACS forums.

Sorry, Gustaf, I thought this was a language specific question better suited
for here. My mistake. I will keep future posts in the forum. Thank you
for the help.

On Fri, May 16, 2008 at 11:06 AM, Gustaf Neumann <neumann_at_wu-wien.ac.at>
wrote:

> Dear Matthew,
>
> the question is more of an OpenACS question than an XOTcl question.
>
> however, some answers:
> - i was the "someone" who wrote a sample script for you.
>
> > in the lines:
> > ::xo::cc set_parameter master 0
> > ::xo::cc set_parameter content-type $content_type
> > what does the "::xo::cc" mean?
>
> - ::xo::cc is an the connection context object created by xotcl-core.
> - The connection context object contains per request information
> - The conneciton context ist used as well by the "view" method of
> XoWiki pages to control, whether or not the output should be
> included in a master adp file (with login etc or not). You will
> not like to have this around e.g. a json code.
> > If the object is being created, how do I reference the object?
> i have to assume, that by "object" you refer to an instance of the
> class ::xowiki::Object. If you load the prototype page - as described
> in my answer in the openacs forum - then an acs_object is
> created in the openacs content repository. The entries in the
> OpenACS content repository are referenced by name.
> When you call e.g. http://..../xowiki/PAGEAME, an
> ::xowiki::Object with the name PAGENAME residing
> in the content folder for the xowiki-instance will be fetched
> from the content repository, on this object, the method view
> is called, and the ouput is presented to the user.
>
>
> > For instance, I would like to set a
> > variable to "content". How would I do this?
>
> From your other positing in the OpenACS forum i see
> that you want to include the page in some other adp page
>
> you can do this
> <include src="/packages/xowiki/lib/view" url="_at_url_at_"
> template_file="view-links">
>
> The variable "url" should point to the xowiki page to be included (e.g.
> /xowiki/my_page).
> best regards
> -gustaf neumann
>
> PS: it makes sense to concentrate the discussion to one place, e.g. the
> OpenACS forums.
>
>
>

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 17 Feb 2001 04:18:27 +0200 (EET)

Code:

Class Foo

Foo instproc init {} {
  puts [[self] info args myMethod]
}

Foo instproc myMethod {anArgument} {}
Foo ob
==> expected a tcl method name but got myMethod


This works as expected if I simply create an Object as follows:

Object foo
foo proc myMethod {anArgument} {}
foo info args myMethod
==> anArgument

Is this behaviour to be expected, and if so, why?

         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

From: Victor Mayevski <vitick_at_gmail.com>
Date: Mon, 11 May 2015 09:14:48 -0700

Hello Gustaf,

Is it possible to implement a custom handler for undefined/unknown
properties, similar to unknown method that handles undefined/unknown
methods?

Thanks