Weblog Page

From: Victor Mayevski <vitick_at_gmail.com>
Date: Wed, 27 Oct 2010 15:58:10 -0700 (PDT)

Very nice. It is even better than I thought. ::Slot has been probably the most confusing part of XOTcl for me, hence I only used it for Attribute.

Thanks


----- Original Message -----
From: "Gustaf Neumann" <neumann_at_wu-wien.ac.at>
To: "Victor Mayevski" <vitick_at_gmail.com>
Cc: xotcl_at_alice.wu-wien.ac.at
Sent: Wednesday, October 27, 2010 12:11:21 AM GMT -08:00 US/Canada Pacific
Subject: Re: nx attribute predefined value constrains, two more possible options?

On 26.10.10 22:58, Victor Mayevski wrote:
> How about adding two move predefined constrains?:
>
> :attribute a:regexp={myregexp}
> :attribute a:glob={myglob}
one can do this with a few lines of code (see below).
In most cases, it is better to name the types (like e.g.
a type isbn), such that the matching pattern/regexp does
not have to be repeated on each usage.

-gustaf neumann

==============================================
::nx::Slot method type=glob {name value pattern} {
   if {![string match $pattern $value]} {
     error "Value '$value' does not match pattern '$pattern'"
   }
}

Class create C {
   :attribute x:glob,arg=*world
   :public method foo {a:glob,arg=*x b:glob,arg=*y} {
     return $a-$b
   }
}

#C create c1 -x abc; #Error: Value 'abc' does
not match pattern '*world'
C create c2 -x "hello world"
c2 foo xxx yyy
#c2 foo x aya; #Error: Value 'aya' does not match
pattern '*y'

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Thu, 2 Sep 2004 22:52:48 +0300 (EEST)

On Thu, 2 Sep 2004, Artur Trzewik wrote:

> Am Donnerstag, 2. September 2004 20:55 schrieb Kristoffer Lawson:
>> % package require XOTcl
>> 1.3
>> % xotcl::Class Foo
>>
>> ::Foo
>>
>> % Foo instproc bar {a} {puts $a}
>> % Foo ob
>>
>> ::ob
>>
>> % ob info args bar
>> % ob info body bar
>>
>> Or have I misunderstood something about what should be going on? I would
>> assume args to return 'a' and body to return 'puts $a'?
>>
>> Do they only work on procs? Does that not slightly go against the 'slot'
>> idea?
>
> Please use
> Foo info instargs bar
> Foo info instbody bar
>
> ob info args bar
> works only for procs (procs owned by object ob)

Yes, I found those things, but the documentation talks about methods.
To me, methods mean everything. If it only means procs (not instprocs), I
think it should be really clear about that.

I'm not even sure if it's a good idea that it only means object procs.

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 02 Jan 2012 18:54:40 +0100

Great! many thanks... -gn

On 02.01.12 17:31, Stefan Sobernig wrote:
> XOTcl 1.6.7 is now available for Debian:
>
> http://packages.qa.debian.org/x/xotcl.html
>
> //stefan
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 14 Aug 2001 15:33:56 +0300 (EEST)

On Tue, 14 Aug 2001, Gustaf Neumann wrote:

>
> however, it would be still nicer to have methods as objects.

It's a nice idea, but how do you solve the infinite recursion problem?
If all methods are objects, then methods on method objects should also be
objects and thus have methods etc.

Another related issue would be to make all messages objects so you could
freely ask information on every received message.

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

From: Michael Schlenker <schlenk_at_uni-oldenburg.de>
Date: Mon, 25 Nov 2002 13:41:54 +0100

Uwe Zdun wrote:

>Hi Michael,
>
>I've fixed recently a bug in which the same error message was reported, but
>there the xotcl lib was found correctly. perhaps you've encountered the same
>problem. Can you test this version please:
>
> http://wi.wu-wien.ac.at/~uzdun/xotcl-full-1.0-win-tcl8.4.1.zip
>
>and report your experiences? If it does not work, can you also test, whether
>XOTcl is loaded or not:
>
>
Thanks. Now it works as expected (although the windows installer is a
bit selective about it's invocation path).

Tested against the download version from xotcl.org which doesn't work
and your new version, which does work.

XOTcl lib seems to work from within starkits and unwrapped now without
the error message. (not tested extensivly yet though)
(It did work before, but with the mentioned error message).

Michael Schlenker

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 15 Mar 2006 10:46:58 +0100

Scott Gargash schrieb:
>
> Hello,
>
> Is it possible to change the -setter command associated with a
> parameter at some point other than class definition?
>
one can use the method "parameter" at any time to add/redefine
parameters (see below).
>
> I want to trigger some side effects from a parameter set operation,
> but I can't trigger the side effects until after other things have
> been initialized, so I want to use the default setter method until the
> end of init, and then replace the setter method (but not the getter
> method).
>
technically speaking, if one would like to use a single name for a
setter and getter (such as
set r [a1 foo]; a1 foo 123) there has to be a single method named "foo",
handling both cases.
this is not more than a conveniance, one can define an kind of methods
that behave as accessor
functions.
>
>
> I can override create a parameter-named method at init time, but that
> overrides the getter along with the setter. I'd rather not have to
> handle the -getter from my proc (the default -getter is fine and 2.5x
> faster). I've looked through the docs and the tutorial and I can get
> tantalizingly close (parametercmd), but is there an easy way from
> within a proc to change the -setter properties of a parameter?
>
the difference in speed is due to the fact that the default
setter/getter method is implemented in C,
whereas the tailored functions are in tcl. it is certainly possible to
program a tailored getter method
in C as well, but i doubt that this is worth the effort.

see below for more variations about your example. Aside from these options,
you can use variable traces to trigger side effects from set/get/unset
operatons.

-gustaf neumann

########################################

Class create A -parameter {{foo 1}}
A instproc foosetter {var val} {
  # Do something with [self] that isn't valid pre-init
  puts [self proc]
  my set $var $val
}

A create a1 -foo 234 ;# calls default foo setter
# redefine setter for class A
A parameter {{foo -setter foosetter -default 1}}

a1 foo ;# calls default foo getter
a1 foo 123 ;# calls overridden foosetter
puts foo=[a1 foo]

A create a2
a2 proc foo {args} {
  puts "object specific getter/setter for [self proc] $args"
    switch [llength $args] {
      0 {my set [self proc]}
      1 {my set [self proc] [lindex $args 0]}
      default {error "use [self proc] with 1 or 0 arguments"}
    }
}
a2 foo 567 ;# call proc foo as setter
puts foo=[a2 foo] ;# call proc foo as getter

From: Laurent Duperval <laurent.duperval_at_netergynet.com>
Date: Mon, 11 Dec 2000 08:11:46 -0500 (EST)

Hi,

TO follow up on my previous message, I'd like the following not tothrow an
error:

Class Abstract abstract instproc foo args
Class NotAbstract -superclass Abstract
NotAbstract instproc foo {arg1 arg2} {}
NotAbstract obj
.
.
.

L

-- 
MY EMAIL ADDRESS HAS CHANGED --> UPDATE YOUR ADDRESSBOOK
Laurent Duperval                   "Montreal winters are an intelligence test,
Netergy Networks - Java Center            and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:laurent.duperval_at_netergynet.com           Penguin Power!

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 18 Dec 2000 23:57:10 +0200 (EET)

I haven't yet got round to upgrading to 0.83 and the upgraded xodoc tool,
but I'd like to know how it reacts to splitting up a package into several
files? Ie. I have one large file with lots of classes but to structure
it more neatly I am moving parts of it into other files with the same
package name so that "package require" gets all of them. Will this affect
the operation of xodoc? Specifically I'd like to know what happens
when using the "_at_ File" system as I'd probably like to document each
file separately like that.

In addition all the classes in the different files are evaled into the
same namespace, so xodoc should handle this too.

On another issue we have made Debian packages of XOTcl (0.82, but 0.83 is
on the way) if someone is interested.. They're not extensively tested but
they seem to work on the machines here. Probably candidates for merging
into the official Debian system at some later time.

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 30 Nov 2011 00:02:05 +0100

On 29.11.11 18:39, Victor Mayevski wrote:
> Hello Gustaf,
>
> What would be a good way to define a constant/immutable
> property/variable in Next?

Dear Victor,

Below is a short study to set all current instance variables
of an object immutable based on variable traces. To
implement the immutable functionality on the property level
is more involved, since one has to handle
default/non-default cases, and one has to register the
traces at the right time for every object creation.

Maybe this simple study helps already

-gustaf neumann

==============================================================
package req nx
package req nx::test
package req nx::trait

::nx::Class create C {
   :require trait nx::traits::callback

   #
   # Method called via trace to reject write operations
   #
   :public method reject {name sub op} {
     error "$op operation on variable $name of object [self] is not allowed"
   }

   #
   # Method to make all currently defined variables of an object
   # immutable
   #
   :public method immutable {} {
     foreach v [:info vars] {
       ::trace add variable :$v write [:callback reject]
     }
   }
   :create c1 {
     set :x 1
     set :y 2
   }
}

c1 immutable
? {c1 eval {set :x}} 1
? {c1 eval {set :y}} 2
? {c1 eval {set :x 1}} {can't set ":x": write operation on variable :x of object ::c1 is not allowed}
? {c1 eval {set :z 3}} 3

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Tue, 20 Jan 2015 09:15:30 +0100

Hi Victor,

> Any suggestions?

As always, there are several options. One way of nursing our custom
Object/Class is to use proper specializations of nx::Object/nx::Class:

package req nx

namespace eval ::vitick {

   Class create Object -superclass nx::Object

   Class create Class -superclass nx::Class {
     :method init {} {
       :configure -superclasses [namespace current]::Object
     }
   }

   namespace export Object Class
}

namespace import -force ::vitick::*

This is less invasive and you have the benefit of monitoring any
changes/additions to nx::Object/nx::Class for free.

Cheers,
Stefan