Weblog Page

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sun, 19 Mar 2006 13:08:40 +0200

On 19 Mar 2006, at 00:12, Scott Gargash wrote:
>
> When would you need the namespace of the object? If all you have
> is the reference (the handle is truly opaque), you'd have no
> knowledge of the namespace of the object. Containment would have
> to be implemented instead of just inferred, but if it's implemented
> it could have new properties.
I have only ever needed the namespace of an object which attaching
traces to variables (f.ex. with Tk), but for that it is,
unfortunately quite necessary.
> As an aside, I find Tcl's lack of true references to be one of its
> nagging flaws.
Yes, this is a problem. If Tcl had proper references then we could do
garbage collection for objects. The problem is that Tcl's principle
of everything being a string kind of conflicts with references.
References can be represented as strings, although not very useful
strings, but they really aren't strings. I mean, if the string output
for a reference is 0x123456, but I generated that through some other
string operations (or, say we lose the original Tcl object through
various operations) then that will no longer necessarily work as a
reference if the original is gone.

This is particularly problematic as Tcl still has quite a habit of
losing that original representation which naturally I hope will be
reduced in the future.

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

From: Attilio Dona` <attilio.dona_at_telecomitalia.it>
Date: Fri, 16 Apr 2004 17:19:29 +0200

Hy,

Thanks to XOTcl I'm rethinking the OO paradigm and doing metaprogramming
easier.

1. Parameter introspection

I use the Metaclass concept to model metainfos and use the parameter
command to add meta-attributes runtime.
As already You pointed out the parameter introspection (className info
parameter) mechanism is not correct, so it is needed some parsing, with
euristic regexp, to extract the parameters info.

Also the command:

className info parameter parameterName

doesn't work as expected, because it ignores parameterName

Have you planned to release in the near future the fix to this problem?


2 Parameter strange behavoir

When using Parameter command I have noticed same strange behavoirs, for
examples:

case 1:
Class X -parameter {{-x 100}}
::X

case 2:
Class X -parameter [list {-x 100}]
wrong # args: ....

case 1 and 2 are perfectly equivalent, so I think there is same strange
parsing inside a C function. Also note that this is true only for "negative"
attribute, ie: Class X -parameter [list {x 100}] work as expected.

Attilio



  
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster_at_telecomitalia.it.

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Thu, 7 Apr 2005 10:12:18 -0700

The following is a patch to upgrade a pristine xotcl 1.3.6 to the
latest TEA 3.2:

        ftp:/tcl.activestate.com/pub/incoming/xotcl.changed.patch.gz

I would recommend including it for 1.3.7. Nothing major, but it
adds support for a few odder platform variants.

Jeff

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 1 May 2004 02:57:10 +0200

Dear Attilo,
thanks for your suggestions and report

On Friday 30 April 2004 15:05, Attilio Dona` wrote:
> In 1 I report an introspection bug, in 2 an ahestetic bug and in 3 a
> personal consideration about a possible XOTcl improvement.
>
> 1. Introspection: "info methods" duplicated entry
> ...
> lsort [Class2 info methods]
> result: __next a a abstract ....
> expected: __next a abstract ....

 well, there is a simple fix :), use
 lsort -unique [Class2 info methods]

 i have fixed the xotcl code such it does not return duplicates.
 the fix slows down "info methods", since it performs
 a linear search for each method (quadratic behavior),
 but in most apps, it is not called too often, so it might be ok.

> 2. Usage string
>
> Object n
> n info children -class Interface
> wrong # args: should be {::n info children ?pat?}
>
> I expect:
> wrong # args: should be {::n info children}
>
> or there is somethig missing in the language reference documentation?

 correct. it was a documentation bug, the pattern was not described.
 you can specify a pattern for matching the name for "info children"
 and "info classchildren"

> 3. Dynamic Object aggregation improvement issues
>
> I think would be useful, especially for performance reasons, that
> dynamic object aggregation have more introspection functionalities at
> core language level:
> for example at the info children command could be added options that
> returns children filtered by children class (and object names and ... ?)
>
> More in general,an useful feature could be returning all children that
> match some assertions (something like an invariant list)

 This is a more complex issue, i have thought about a couple of times.
 In general it would be quite nice to have a object query interface
 that allows you to say "find me the objects having these and that
 instance variables set, that are children of some other object,
 have these or that classes, mixins, or whatever". It would be
 certainly quite nice to use e.g. XPath as a query language for this
 purpose. An easy approach would be to produce an xml tree
 using tdom from the interesting objects and use tdoms xpath
 implementation. tdom is very nice and fast, and i would not
 be suprised if that would be sufficiently efficient for many apps.

 most proably this would not sufficient for your app, since you
 are already concerned about looping over the info children
 list. maybe you can use the following to approaches:

   - if you have less class instances than aggregations,
     use info instances with a match pattern instead. e.g.:

       Dog info instances ::stable::*
       Cow info instances ::stable::*
  
     these command will return you the Dogs or Cows wich are
     in the container stable.

   - If you have a huge number of container and a huge number of
     instances, use an index in form of an associate array. you can
     maintain it whenever you create/destroy/reclass an object (e.g.
     through constructor/destructor)
           
 i'll send you a fixed version with a separate file.

 all the best
-gustaf

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

From: Maurice Diamantini <diam_at_mac.com>
Date: Sat, 6 Jul 2002 14:12:24 +0200

Bonjour à tous,

I'd like to try a tcl object system, but I'm looking for a system
that support a lite version in tcl only, so that I can keep an
interpeted version of an application.

I know there is stooop which has the big advantage of beeing
part of the tcllib. But I dont like C++ very much (:-), and I'm
not sure there is a compiled version of stooop

There is itcl for which there is a tcl only lite version.
The advantage of itcl is that it is very wide range ported,
and it seems easier to install that xotcl. Also I is to
be much like a standard tcl extension.

But I like the concept of xoctl, which seems more
dynamic and powerfull than itcl, and keep the tcl phylosophy

So my question is :
Does a tcl only version of xotcl exists (or about to exists)
which would be a subset of xotcl.

The main fonctionnality I like is a simple inheritage feature
and some introspection (which methods is supported by
this class?, ...)

If such a xotcl-lite version could be put is the tcllib, then
I think it would be the best mean to make xoctl widly use
(and the the standard tcl object system)

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sun, 16 Jul 2006 15:52:46 +0300

On 16 Jul 2006, at 14:53, Gustaf Neumann wrote:

> Kristoffer Lawson schrieb:
>
>> Usually one works on a development version where all debug options
>> and checks are turned on — you want to capture anything as soon as
>> it happens. Then you turn them off for a delivery version (if for
>> no other reason than to enhance performance).
> no question, useful scenario. allthough, the notion of "everything"
> might be different in various cases. sometimes, really all objects
> are the scope of the checking, sometimes "user code", file scope,
> namespace scope, class scope or object scope. the lowest common
> denominator is the object. this looks to me as a good thing for a
> library function (package).

Personally I think the most common and logical ones would probably be
"everything", "these classes" and "this object".

>> As with most functionality in XOTcl there is the 'inst' methods,
>> which are often given to classes, and then the direct ones for
>> objects. Thus it would seem logical to have that for asserts as well.
> i am not so convinced about the "inst" variant. "inst" means,
> provide some resources for the instances of a class, usually the
> instances can decide to override/extend it. what happens, if the
> inst rule turns checking on/off but the instance turns if off/on,
> or sets different values, etc. this is different to what we have
> discussed so far, and not terribly important imho. A package makes
> more sense, which makes it easy to extend/modify the behavior.

I think that extending would still be perfectly fine. I mean,
basically what would happen would be that all instances would have
certain checks on, by default. This could then be changed on a per-
object basis.

>>
>> Neither of our solutions are really the kind of thing basic coders
>> would come up with.
> providing a few general idioms makes the developer more productive
> on the long range than one more built-in.

Well, in theory that could be said about the whole assertion system,
which could be done with filters and similar. Perhaps not even a bad
idea. Some things are useful for convenience and perhaps even
performance. The balance needs to be good, and I think if a feature
is in there, it should exist in completeness.

That's just my perspective as a developer but obviously you are the
designers behind the extension, so it is your call which features you
feel are important and which not.

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

From: Zoran Vasiljevic <zv_at_archiware.com>
Date: Tue, 22 Nov 2005 12:01:25 +0100

On 22.11.2005, at 11:17, Zoran Vasiljevic wrote:

> Hi!
>
> What I need to do sometimes is to be able to cache
> classes because their creation (in our case) might
> be a costly operation.
>

Actually "Object naming and creaion" should be the
correct subject, as I would really need to intercept
the "new" and "unknown" and install custom code when
somebody does:

    Foo new
or
    Foo bar

Zoran

> For example:
>
> Class HeavyClass
> set hc [HeavyClass new]
> $hc whatevermethod
>
> can be quite time consuming. What I'd like to do
> is to "cache" "things" created by "new" or even
> for:
>
> HeavyClass hc
> hc whatevermethod
>
> What would be the best way to achieve this caching?
>
> Thanks for help.
> Zoran
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Fri, 18 Feb 2011 12:58:54 +0100

Victor,

> Am I doing something wrong?

No, what you scripted is perfectly fine (by intention), you just
revealed a collateral (in my understanding):

Right now, there is no ::nx::Object->unknown() defined, which would be
the [next] target. Therefore, [next] does not give you what you expect.
If you look in nx.tcl, it is simply commented out.

In the commit
http://fisheye.openacs.org/changelog/xotcl/?cs=//xotcl/67ad561b71e208451454fc1d71e591e75e4f3a71
changes where applied to make a scripted unknown method on the root
class (::nx::Object) unnecessary.
however, these changes do not cover the case of refining this built-in
unknown "method".

a quick workaround for the scope of your application is to define
::nx::Object->unknown() at an early stage:

::nx::Object protected method unknown {m args} {
   error "[::nsf::self]: unable to dispatch method '$m'"
}

or simply signal the error in your application-level unknown:

C method unknown {m args} {
   if {$args eq "test"} {
     puts "found test";
     return
   }
   error "[::nsf::self]: unable to dispatch method '$m'"
}


for an authorative fix i would need to understand why these changes
happened in the first place which i don't, frankly. was the intention to
remove unknown from ::nx::Object method record entirely? i hope not ...
but gustaf is the authority here.

//stefan

From: Kurt Stoll <kstoll_at_echelon.com>
Date: Sun, 24 Jun 2012 15:54:43 -0700

This looks wrong to me, but I could be wrong - maybe there are prohibitions somewhere that would tell me not to do this.

If I define an Attribute "list", and then use the Tcl list command within the assign (and, presumably, other procs of the attribute as well), the attribute's unknown handler is called reflecting an odd invocation. I would suspect that other "overloading" (this is not really overloading, but looks similar so I have used that term; I apologize it that confuses you) of Tcl commands as Attributes would result in similar problems.

First, here is a simple Test class without overloading the list command to demonstrate the expected behavior. Note that I redefine unknown so that I can verify the order of the invocation:

(Warning - I submitted a question with embedded test code some years ago and this caused problems for people when they attempted to copy-and-paste the code. I don't recall exactly what caused the issue, but I am still using the same email client, so this may have similar issues.)

Class create Test1 -slots {
    Attribute create alist -proc assign { obj var val } {
        puts "list <$obj> <$var> <$val>"
        $obj set $var [list $obj $var $val]
    } -proc unknown { val obj var args } {
        puts "unknown: $obj $var $val $args"
    }
}

> ## Create a test object t1
> Test1 create t1
::t1
> ## Call alist setter
> t1 alist 3
list <::t1> <alist> <3>
::t1 alist 3
> ## Check to see that alist variable set properly
> t1 set alist
::t1 alist 3
> ## Force a call to unknown; note that the printed output matches the invocation order
> t1 alist this should call unknown
unknown: ::t1 alist this should call unknown

Now, I create a simple variant. All I have changed is the name of the Attribute from "alist" to "list". But, in this case, when attempting to call the setter, unknown is called (I have done other experiments that showed that it is called when "list $obj $var $val" is called). Also, note that the invocation of unknown is a bit strange; it appears that unknown is directly invoked on the original call (in this case, "t2 list 3"), instead of having the arguments swapped as demonstrated above:

Class create Test2 -slots {
    Attribute create list -proc assign { obj var val } {
        puts "list <$obj> <$var> <$val>"
        $obj set $var [list $obj $var $val]
    } -proc unknown { val obj var args } {
        puts "unknown: $obj $var $val $args"
    }
}

> ## Create a test object t2
> Test2 create t2
::t2
> ## Call list setter. Unknown handler is called.
> t2 list 3
list <::t2> <list> <3>
unknown: list 3 ::t2
> ## See what ended up in the list variable.
> t2 set list

> ## Blank above

Am I wrong to expect Test2 (and t2) to behave just as Test1 / t1 behaved? It's not a serious issue for me; I'll just avoid overloading Tcl commands in this context. But, it was unexpected enough for me that I thought it was warranted for me to ask the experts.

-Kurt Stoll

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Fri, 24 Jan 2003 15:49:47 +0100

On Friday 24 January 2003 15:09, Kristoffer Lawson wrote:
> On Fri, 24 Jan 2003, Uwe Zdun wrote:
> > nice idea, I've played a bit with var traces to make some tie
> > functionality work; is this what you were thinking of?
>
> Yeah, nice going. Looks like exactly what I had in mind (I reckoned you
> could probably do it with Tcl traces). I thinking that I might almost
> prefer if [tie] was not an object command as it's not really related to
> any specific object (f.ex. using it from outside an object would be
> funny). Or what do you think?

its no big deal to do that: for instance see the code below; the problem with
this code sample is you have to be sure that the variable is defined one
level above the trace; if you are not, you'll have to use global variables
only for ties; or you store all tie variables in a special namespace; such as
the xotcl namespace.


proc tie {varname objname} {
    upvar $varname v
    set v $objname
    trace variable v wu "tie_cb $objname"
}
proc tie_cb {tieobj n1 n2 mode} {
    upvar $n1 name
    ## delete the tieobj
    if {[xotcl::Object isobject $tieobj]} {
        $tieobj destroy
    }
    ## delete the trace for this tieobj
    if {$mode == "w"} {
        foreach t [trace vinfo name] {
            set mode [lindex $t 0]
            set cmd [lindex $t 1]
            if {[string equal $cmd "tie_cb $tieobj"]} {
                #puts "delete: $mode $cmd"
                trace vdelete name $mode $cmd
                #puts [trace vinfo name]
            }
        }
    }
}

####################################################### Test

set n 0
while {$n < 10} {
  tie myVar [Object new]
  incr n
}

### only one should have survived
puts [Object info instances]

### test unset
unset myVar

puts [Object info instances]

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at