Weblog Page

From: Victor Mayevski <vitick_at_gmail.com>
Date: Tue, 24 Mar 2009 19:40:43 -0700

In my code, when trying to create a new autonamed instance of one of
my classes, I get the following error:

[ MyClass new ]
invalid command name "::xotcl"

I don't even know where to start looking for the cause of this error
since "new" is a built-in method of XOTcl. This error only happens
with this particular code, other code works fine. Any
tips/suggestions?

Thanks

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Thu, 18 Jan 2001 20:42:18 +0100

Hi,

Most of the time, I know what is going to be called when I peut a next
statement :
        - the class instproc method if from a proc
        - the mixin method if any
        - the superclass method
etc..

My question is the following: I have sometimes the instproc redefined at the
instance level with a proc: this is to enable the user to experiment a method on a given
object without breaking all the application (this is actually one the main
reason for me to use Xotcl). It's also a debug feature for more experimented developpers.

However, I have the "next" problem in such case: it's the instproc level which is called
instead of either the mixin or superclass method.

Is there any way either:
        - to ask by introspection who is going to be called - e.g something like:
                [[self] info next methodname]
        - to enforce it:
                classname next

I know the procsearch command, but it doesn't take a "next" argument!? I have tried :
        puts "procsearch: [[self] procsearch next]"
which gives this output:
procsearch: ::buttondata0::next
(buttondata0 is an instance for which a proc has been defined)
::buttondata0 proc

I don't see any solutions with 'info called/calling' features either?

Many thanks!

-- 
Catherine Letondal -- Pasteur Institute Computing Center

From: Adam Turoff <aturoff_at_bna.com>
Date: Wed, 19 May 2004 11:03:30 -0400

You wrote:
> > Object instproc insert_mixin {mixin_list} {
> > my mixin [append mixin_list " " [my info
mixin]]
> > }
>
> with names like mixinappend, mixinprepend for mixins,
filters,
> instmixins, instfilters we would introduce a large number
of
> methods, which do more or less the same.

Yes. That is certainly a problem.

> what do you people think about the following "interceptor"
> method: it is more verbous, but much more powerful as
well; it
> allows appending/prepending/inserting at a certain
position and
> deletion of all kinds of interceptors:

Hm...

One minor niggle is the use of the term 'interceptor'. The
term is quite
overloaded. First, this instproc manages two kinds of
'interceptor'
interfaces for an object: mixins and filters. Second, the
proc itself
is an interceptor -- it traps calls to manage the mixin and
filter
lists. Third, as you have written this proc, it manages
both mixins and
filters, which makes them appear more similar than they
really are.


That said, I do think you are on to something. The core
problem is that
both filters and mixins are a list of classes, and there are
no good
primitives to manage that list in a natural manner. It
would be nice if
[my info mixin] and [my info filter] were mutable with list
commands, but...

So, for the sake of argument, let us assume that there are
two new
instprocs - one to manage the list of filters, and one to
manage the list
of mixins (again, better naming ideas greatly appreciated):

    Object instproc mixin_list args {
        set op [lindex $args 0]
        set classes [lrange $args 1 [llength $args]]

        switch -exact $op {
            append { my mixin [concat [my info mixin]
$classes] }
            prepend { my mixin [concat $classes [my info
mixin]] }
            set { my mixin $classes }
            get { my info mixin }
            delete { ... }
        }
    }

    Class A
    Class B
    Class C

    A a
    a mixin_list append B
    a mixin_list prepend C
    a mixin_list get
    ================
    ::C ::B

Adding new primitive operations (like a mixin_list length; a
mixin_list sort;
a mixin_list contains classname; etc.) is simple and
obvious. I haven't played
with filters yet, but this idiom should work well there,
too.

I'll leave it to you to determine whether this method should
work use
instmixin for Classes, and mixin for Objects.

-- Adam

From: Arthur Schreiber <schreiber.arthur_at_googlemail.com>
Date: Fri, 10 Feb 2012 11:45:08 +0100

Hello Gustaf,

Is not being able to call protected class methods from instances intended
behaviour?

Here is a very simple test case:

package require nx

nx::Class create Greeter {
    :class protected method say_hi {} {
        puts "Hello!"
    }

    :public method say_hi {} {
        [:info class] say_hi
    }
}

[Greeter new] say_hi

Also, protected methods can not be called from instances of the same class,
e.g.:

package require nx

nx::Class create Greeter {
    :public method say_hi { other_greeter } {
        $other_greeter protected_say_hi
    }

    :protected method protected_say_hi { } {
        puts "Hello!"
    }
}

set g1 [Greeter new]

[Greeter new] say_hi $g1

Kind Regards,
Arthur

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 22 Nov 2005 15:08:46 +0100

Zoran, does this help? it will print

   ::xotcl::Class wants to create Foo
   ::Foo wants to create ::xotcl::__#1
   ::Foo wants to create bar

You can do this also selectively for certain classes via mixins, or by
defining
an appropriate metaclass.

Greetings,
-gustaf
-----------------------------------------------------------------------------------------------------
Class instmixin add [Class new -instproc create {object args} {
  puts "[self] wants to create $object"
  next
}]

Class Foo
Foo new
Foo bar

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 17 Mar 2006 15:33:27 +0100

Kristoffer Lawson schrieb:

>
> But I am guessing even this is unnecessary. Why call the destroy at
> all? I am confident, without looking at the actual code, that
> deallocation of the resources for the 'original' object could be
> deallocated without going through the whole destruction procedure.

as pointed out earlier, move is a copy + destroy.
If you want a copy alone, use copy and not move.

As Artur pointed out, command names are the references to objects.
if such a reference should be made invalid and the unneeded
storage should be reclaimed at this time, destroy is the correct thing.

Note, that move does not refer to a single object, but to an object tree,
all subobjects, classes, commands, etc. are affected as well.

-gustaf neumann

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 26 Mar 2006 13:25:14 +0200

Scott Gargash schrieb:
>
> xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/21/2006 02:28:15 AM:
>
> > i do not like the &-suggestions for the xotcl-core, since it looks
> > like an operator, not like a name. The &-operator is not
> > about fully qualifying a name, but about providing a reference
> > in general.
>
> What's the difference (in tcl) between a name and an operator or a
> name and a reference?
>
> I'm not being sarcastic, you're making a distinction I don't see.
>

i don't think, that you are expecting an detailed anwser. for example, a
prefix operator is a
syntactical construct you can put in front of some other syntactical
construct to express
some intention. One can for example put a "-" in front of a number to
express that
you want to use its negative value. Similary, one can put a "$" sign in
front of every
variable name in tcl to access the value of the variable. I would expect
from a
operator & to be as general, to work the same way, no matter whether the
variable is
global, on a stack frame, or in an object.

> The problem here is needing an external reference to an XOTcl member.
> In Tcl, that means you need the name of the variable.
>
unfortunately this is currently not true in general. To reference e.g. a
variable on
some stack frame, you will need upvar or similar constructs.
maybe someone writes a name resolver to achieve this, or implements a
command
to achieve this a some time. Maybe then someone decides to use & for
such purposes.
>
>
> > i get the impression that adding these cmds/methods do not reduce
> > significantly the clarity. myvar/myvarname makes sense for the
> > snitters.
>
> While that may be true for an experienced user, as a new user trying
> to use XOTcl I find the way XOTcl uses namespaces (created on demand)
> to be pretty confusing. Anything that keeps me from needing to
> understand that is a good thing. And leaving aside the new user
> issue, having a documented access mechanism for clients instead of
> knowledge of the implementation seems like a good thing.
>
Maybe i made the mistake to explain some details (that a normal user
does not need to know)
in order to dicuss the ease and feasability of some proposed constructs.
xotcl tries to hide tcl-namespaces to a good deal, but sometimes they
look through.
as explained earlier, tcl-namespaces are simplifying xotcl in some respects,
in other respects they are a burden.

i certainly agree that providing a standard way of accessing instvars
helps, therefore i think
we should add a command or method to xotcl to do so.

snit uses snit::myvar and snit::varname (just a second name for the
same command)
and snit::mymethod (the latter one as an alternative to [list somemagic
somemethod someargs]).
itcl uses itcl::code for the latter.

So, in order to stick to these names, using ::xotcl::myvar and
::xotcl::mymethod and
exporting these seems as a good idea. Exporting can turn out to be a
problem when
someone uses snit and xotcl at the same time and needs to namespace
import both for
some reason. I am somewhat unhappy that these commands suggest some
non-existing
symmetry (myvar refers to an object-variable, while mymethod constructs
a command
from a method name, and the method name is not restricted to be defined
within a command (or tcl-namespace)).

When using methodnames for the discussed functionality, we should invent
new
names, since [my myvar ... ] and [my mymethod ...] look somewhat strange.
for ::xotcl::myvar, i think [my varname ...] is fine. for mymethod the
naming
is harder. What is an improvement over "[list [self] method args]"?
"my code foo args",
"my cmd foo args",
"my invokecmd foo args",
"my callbackcmd foo args",
"my make_command_from_method_name foo args"

haveing listed these options, "::xotcl::mycmd" looks reasonale
to me, since it constructs a tcl command and avoids the "[self]"
in a similar way as "::xotcl::my".

More ideas, suggestions, comments?
best regards
-gustaf neumann
 

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 13 Mar 2001 10:40:02 +0100

On Tuesday 13 March 2001 10:27, Zoran Vasiljevic wrote:
> Hi !
>
> I strongly suspect that in0.84 version,
> the mixin process is changed, which
> brings some incompatibilities.

 yes, the initialization of per-object mixins changed, and it
 is documented in the changelog (i inserted an exclamation mark
 before the item to denote the potential incompatibility) and in
 the tutorial. i have removed now the obsolete part from the
 language reference and rewrote the section in the tutorial
 more explicit as follows:

----
Note, that the constructors (init methods) of per-object mixins (and 
per-class mixins) are only called, if the mixin is registered already during
object initialization (when init is called). For per-object mixins, one can
achieve the initialization of a mixin via an idiom like 
  Object o -mixin M -init
that registers the mixin before init is called. When a mixin is registered
after object creation and it needs initializations, it is neccessary to 
define special methods for this. Note, that the behavior described here is 
introdoced in version 0.84 to ensure consistent behavior of intrinsic
classes, per-object and per-class mixins, and to achieve predictable 
behavior for dynamic registration for all kind of mixins, and as well during
recreations of objects having mixins registered. Older versions used
heuristics for the initialisation of per-object mixins. 
----
 For your example below, i would recommend to use a per-class
 mixin "... A instmixin B" since the intension is obviously to register
 the mixin for each instance of Class A
 hope, this clarifies 
 best regards
-gustaf neumann
> Please consider this simple example
>
> Class A
> Class B
>
> A instproc init {args} {
>     [self] instvar C
>     [self] mixin B
>
>     set C(Aelement) 1
> }
> B instproc init {args} {
>     [self] instvar C
>     set C(Belement) 1
> }
>
> A instproc foo {args} {
>     puts "[self] A bar"
> }
> B instproc foo {args} {
>     puts "[self] B bar"
> }
>
>
> The 0.83 behaviour...
>
> % A a
> % a foo
>
> ::a B bar
>
> % a array get C
> Belement 1 Aelement 1
>
>
> The 0.84 behaviour
>
> % A a
> % a foo
>
> ::a B bar
>
> % a array get C
> Aelement 1
>
>
> WHERE is the "Belement" ??????
> It seems that 0.84 does not properly calls the "init"
> on the B class before doing an mixin ?
> Or am I missing something completely?
> Any ideas ?
>
>
> Cheer's
> Zoran Vasiljevic
> Archiware
>
> _______________________________________________
> Xotcl mailing list  -  Xotcl_at_wi.wu-wien.ac.at
> http://wi.wu-wien.ac.at/mailman/listinfo/xotcl

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 12 Aug 2010 15:20:17 +0200

  On 11.08.10 19:51, Kevin Van Workum wrote:
> I would like to include XOTcl functionality to my control script, but
> naively using "package require XOTcl" doesn't seem to work.
"package require XOTcl" is supposed to work. In xotcl 1.6.6,
i count
128 occurrences of "package require XOTcl".

If Tcl does not find the package, it might be the case that
you installed it to some
directory not on your auto_path or (TCLLIBPATH, etc.), or
that you are
using a Tcl distribution, not including it. After the
install you should have e.g.

/usr/local/lib/xotcl1.6.6/pkgIndex.tcl
/usr/local/lib/xotcl1.6.6/libxotcl1.6.6.so
/usr/local/lib/xotcl1.6.6/libxotclstub1.6.6.a

You can certainly initialize via C as well (using Xotcl_Init()),
but i would recommend the "package require" way.

best regards
-gustaf neumann

From: Krzysztof Frukacz <frukacz.krzysztof_at_gmail.com>
Date: Wed, 05 Jan 2011 15:50:54 +0100

Hello,

I have a question for which I haven't been able to find the answer.
I have two classes:

Class create A -slots {
        Attribute foo -proc assign {domain var value} {
                if {$var > 5} {
                        error "Value cannot be bigger than 5"
                }
                $domain set $var $value
        }
}

Class create B -superclass A -slots {
        Attribute foo -proc assign {domain var value} {
                if {$var < 0} {
                        error "Value cannot be less than 0"
                }
                #I don't know how to call assign for foo in class A here
        }
}

What I want to to is for assign proc from B to call assign proc from A
too check both conditions.
Thank you for your help.

-- 
Krzysztof Frukacz