Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 28 Sep 2005 19:20:41 +0200

Donal K. Fellows schrieb:

> Gustaf Neumann wrote:
>
>> a) a more radical approach is to move all c-level commands out of
>> object and class into one or more method repositories (similar to
>> namespaces, but just a hash table containing for commands) and
>> let the object system designer link these (private/public, if
>> necessary) into the base classes of an object system. One can
>> design a SnitClass or an XOTcl class or lsay a Java-kind class
>> quite freely, and it provides room for incremental improvement
>> without harming others.
>
>
> The TIP is (totally!) light on C-level API, largely because I've no idea
> what needs to go there. I'd even be happy (personally speaking) with an
> OO system that did not provide any C-level API at all. Other people will
> probably disagree. :-D

i was not talking about the c api at all here. i was refering to the
xotcl methods
implemented in C (e.g. create, destroy, class, forward, mixin ...) being
placed
into a method repository (e.g. a namespace) maybe called ::xotcl::objcmds
and ::xotcl::classcmds and then one can do e.g.

     oo::class ::xotcl::Object -import public ::xotcl::objcmds::*
     oo::class ::xotcl::Class -superclass ::xotcl::Object -import public
::xotcl::classcmds::*
     ::xotcl::Class class ::xotcl::Object

 while people proposing other OO-Systems can import stuff
private/public to any
 kind of class hierarchy they want. In reality this will be more
complicated, but
 you get the idea.
 

>
>> b) We have discussed splitting xotcl classes into smaller components
>> about two years ago. We did not do this mostly since xotcl users
>> would most likely use Obect and Class as it is today.
>
> [...]
>
>> Having said this, i am certainly not sure that "define" leads
>> the right way by moving the methods to manipulate the MR
>> to the top.
>
>
> Having the metadata manipulators outside the primary object hierarchy is
> pretty much a requirement, and it comes from what's needed for
> supporting multiple OO "looks and feels" on top.

hmm, what is a metadata manipulator? i was talking about more primitive
c-level constructs which could help to make tcl (and its oo parts) more
consistent. Read method repository (MR) as hash table of command pointer
and data repository (DR) as hash table of variables. i would like to see a
consitent interface to these as well in ca on the tcl layer and having these
compontents in a better composable way. This would provide a much
better basis for multiple OOs and a better integration with current tcl
core (both ways)

>
>> The TIP writers did not like the fact that general functionality
>> is introduced in xotcl from Object (as it is in Ruby or Smalltalk
>> or many other OO languages). I never found this a problem
>> in real applications. i rather see problems with some low-level
>> stuff, when it is not this way, when classes are destroyed, objects
>> are reclassed, etc. I would feel better, when Object, Class are
>> xtocl-like and and we provide some protection schemes through
>> subclasses.
>
>
> Again, that's driven by supporting other OO systems too.

This can be solved by defining e.g. SnitClass having everything
private except what it wants to publish.

>> I am not going to repeat all earlier discussions here. Is it OK to
>> send improvement proposals for the current TIP here, leaving
>> aside this bigger issues?
>
>
> The best place to discuss things is really the tcl-core mailing list.

i have to figure out, where this is...

>
> BTW, I was wondering what happens when you do this in XOTcl (ignoring
> the syntax for now):
>
> class A derived from Object
> defines instproc foo
> class B derived from A
> defines instproc bar
> class C derived from Object
> defines instprocs foo, bar and move
>
> object D is a C with B mixed in
> call: D foo
> call: D move
>
> Which implementation of foo gets called first? Which implementation of
> move gets called first?

as kristoffer pointed out, there is only one move, so there is no
ambiguity. In general the precedence order is
   per-object-mixins per-class-mixins self-procs class-hierarchy

The introspection command for this is
    D info precedence

-gustaf

>
> Donal.

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 16 Nov 2007 11:38:00 +0100

Dear XOTcl developers.

Some of you might be interested in the new Eclipse DLTK 1.0 M3 Release
(DLTK stands for D(ynamic) L(anguage) T(ool)K(it)) which contains
explicit support for XOTcl.

For more details, see the Eclipse XOTcl support plan

   http://wiki.eclipse.org/XOTcl_Support_Plan

or the annoucement in c.l.t with some screen shots

  
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/90eb038bcfdb90fc

Good news!

-gustaf neumann

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

Scott Gargash schrieb:

> xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/15/2006 04:23:28 AM:
>
> >
> > On 15 Mar 2006, at 12:17, Gustaf Neumann wrote:
> > >
> >
> > I am actually quite surprised to find that the move operation calls
> > the destructor. This is not mentioned on the reference manual and
> > does, in fact, seem counter-intuitive. A move is a move, nothing is
> > being destroyed, so why call the destructor?
>
> I agree. A move operation didn't imply object destruction to me, either.
>
i would not expect this either, but it seems as a reasonable compomise.
It has been
like this since implemented more than five years ago and has not caused
any trouble.
maybe, it would have been better to provide only a copy operation, and
delay move,
until it can be made properly in c with a namespace rename operations.
anyhow,
for now, i have documented the copy+destroy operation in the manual.

>
> I'm guessing that xotcl::object's "destroy" method does all the heavy
> lifting (cleaning up the source of the move). What would happen if
> the default move implementation was to change the source object's
> class to xotcl::object before invoking destroy? This way it would
> continue to use the xotcl::object's "destroy" implementation for
> cleanup purposes without invoking all of the subclass destroy methods,
> and derived classes wouldn't perceive move as a destroy operation.
> Would this have bad side-effects?
>
for some applications, it might be the right things, for others not.

>
> While I'm no poweruser, I did get the guard mechanism to work. Here
> it is for completeness sake. (Is there an easy way to search the mail
> archives? Maybe this will help someone else...)
>
This qualifies you at least as a candidate for a power user :).
you might place this on the tcl wiki (http://mini.net/tcl/XOTcl)

mailman has no nice search interface, maybe we will switch at some time
to something better....
best regards
-gustaf neumann

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 21 Oct 2006 10:33:19 +0200

Kristoffer Lawson schrieb:
>
> I don't mean the state of the object at time of calling, in the sense
> of slots, but the values passed to the constructor on object creation.
> The args to 'init'. The reason for this is that it might not be enough
> to just create the object with the appropriate state, but it might
> need to go through the 'init' stage as well, so the proper
> initialisation chain is done (f.ex. might be calls to other things
> taking place there, registration with managers etc). After that, slots
> can be set.
i see, you mean the per-object parameterization; the arguments to the
object/class creation are not stored explicitely
in XOTcl. However, the simplest way to save these is to provide a
per-class mixin for overloading the standard
configure behavior. The following should do it:

  Object instmixin add [Class new -instproc configure args {my set
__configure_values $args; next}]

Now we create a class and a few objects

  Class C -parameter {{x 0}}
  C create c1
  C create c2 -x 10
  C create c3 a -x 100

... and print the stored configure values:

  puts [list [c1 x] [c1 set __configure_values] \
          [c2 x] [c2 set __configure_values] \
          [c3 x] [c3 set __configure_values] ]

  # outputs: 0 {} 10 {-x 10} 100 {a -x 100}

Naturally, this works for classes as well:

  puts [C set __configure_values]

  # outputs: -parameter {{x 0}}

Does this help?

-gustaf neumann

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 23 Feb 2006 19:04:37 +0100

Dear Tcl Community,

Thanks to Uwe, the windows binaries are now on www.xotcl.org.

This is most probably the last time that we provide tcl8.3* binaries.
Tcl 8.4 is out since 2002, i think there is little reason to use tcl 8.3
now. The incompatiblity is for the tcl scripts only, the c code does
not depend on tcl 8.4. For comparisons, we are moving
towards using "eq" and "ne" where appropriate. If you want
to normalize comparisons in older scripts as well, drop me a note,
i have a script for doing these changes...

best regards
-gustaf neumann

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Fri, 17 Jul 2015 18:00:13 -0500

OpenACS contains for XOTcl 1 compatible slot interface for the basic
slot features.
The advanced slot features were marked in XOTcl 1 as "experimental",
some of these
will require some work in XOTcl 2. The NX slot-system is much more advanced
and regular than the XOTcl-1 predecessor, therefore we made this short
cut, knowing,
that some power-users will need some fiddling. if there are problems,
we try to help as usual.

greetings from mx
-gn

Am 16.07.15 um 04:47 schrieb Stefan Sobernig:
>> PS: For novices the "mixture" of ::nx and ::xotcl is a bit
>> unexpected, for
>> example when serializing ::xotcl::MetaSlot on my OpenACS instance,
>> one can
>> see, that e.g. the superclass of ::xotcl::MetaSlot is ::nx::MetaSlot et
>> cetera. My intuitive expectation was that both XOTcl 2 and NX exist as
>> different languages within NSF, but more or less completely isolated
>> from
>> each other.
>
> XOTcl building on NX (esp. slots) is hinted at some spots in the
> migration guide at
> https://next-scripting.org/xowiki/docs/nx/nx-migration/index1#_parameters_2.
>
>> I suppose the reason is to keep the source code required to
>> support the "legacy" XOTcl syntax as small as possible?
>
> So it is.
>
> Stefan
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Univ.Prof. Dr. Gustaf Neumann
WU Vienna
Institute of Information Systems and New Media
Welthandelsplatz 1, A-1020 Vienna, Austria

From: <mail_at_xdobry.de>
Date: Wed, 22 Nov 2006 15:41:23 +0100

Hi!

It's not a bug it's a feature.
Children object can be accessed per shortcuts like methods.

my mychild childmethod par1 par2

It can be confusing about reading such code.

therefore I use by coding XOTclIDE convencion that all child objects
beginns with _at_
Also XOTclIDE syntax checker will understand this.
so the code will look

my _at_mychild childmethod par1 par2

Anyway I use often methods call like this

[my info parent] parentMethod

why not a shourtcut for it

my parent parentMethod

Artur Trzewik

>Hi,
> I just joined this list to get this help. I am seeing this behaviour.
>It is giving lot of inconvenience to me. I want to know if it is a bug
>or not -?.
> In short, if I have a children object as the same name as parent
>object's proc/instproc . The parent object's method is not getting called.
>
> Here is a sample code.
>
> Object a
> Object a proc name {} {
> return "I am valli"
> }
> a name # returns "I am valli"
> Object a::name # Child object with same name as the proc
> a name # returns ::a::name and not the previous message
>
> Is this the desired behaviour. Is there any workaround.
>
>Regards
>Vallinayagam
>valli_at_ezorder.in
>
>
>_______________________________________________
>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: Mon, 02 Jan 2012 17:28:32 +0100

Victor,

> Maybe this simple study helps already

I just recovered a variation of Gustaf's study which I had used in
previous projects of mine. The study below differs with respect to
enforcing the "immutability" (prohibiting vs. preserving state) and adds
handling of variable unsets. It slightly optimizes over the method
dispatch for write traces (using ::nsf::set::var), however, it also
comes at extra costs (doubled variable writes).

It can be easily extended for supporting basic introspection, kinds of
"/obj/ info immutables" or the like ...

//stefan

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

::nx::Class create C {
   :require trait nx::traits::callback
   #
   # Make selected (by default, all currently defined) variables of an
   # object immutable
   #
   :public forward immutable %self traces add

   #
   # Make selected (by default, all currently defined) variables of an
   # object mutable (again ...)
   #
   :public forward mutable %self traces remove

   :protected method traces {op args} {
     foreach varName [expr {[llength $args] ? $args : [:info vars]}] {
       set writeCmdPrefix [list ::nsf::var::set [self] $varName [set
:$varName]]
       set unsetCmdPrefix "$writeCmdPrefix; [:callback immutable $varName]"
       ::trace $op variable :$varName write "$writeCmdPrefix;#"
       ::trace $op variable :$varName unset "$unsetCmdPrefix;#"
     }
   }
   :create c1 {
     set :x 1
     set :y 2
   }
}

#
# c1 is mutable ...
#
? {c1 eval {set :x}} 1
? {c1 eval {set :y}} 2
? {c1 eval {set :x 5}} 5
? {c1 eval {set :x}} 5
? {c1 eval {unset :y; set :y}} {can't read ":y": no such variable}
? {c1 eval {set :y 4}} 4
? {c1 eval {set :z 3}} 3

#
# c1 becomes immutable ...
#
c1 immutable

? {c1 eval {set :x}} 5
? {c1 eval {set :y}} 4
? {c1 eval {set :x 1}} 5
? {c1 eval {set :x}} 5
? {c1 eval {unset :y; set :y}} 4
#
# Subsequent unsets are handled ...
#
? {c1 eval {unset :y; set :y}} 4
? {c1 eval {set :y 2}} 4
? {c1 eval {set :z 3}} 3

#
# c1 becomes mutable (again ...)
#

c1 mutable

? {c1 eval {set :x}} 5
? {c1 eval {set :y}} 4
? {c1 eval {set :x 1}} 1
? {c1 eval {set :x}} 1
? {c1 eval {unset :y; set :y}} {can't read ":y": no such variable}
? {c1 eval {set :y 2}} 2
? {c1 eval {set :z 3}} 3

From: <vitick_at_gmail.com>
Date: Tue, 26 Oct 2010 13:47:11 -0700 (PDT)

I was reading the migration guide, and at the end it talk about the incompatibilities. I have specifically tested the "Calling objects like methods" and I do not understand it. It just doesn't work right.
Example:

Object create a;
Object create a::b

a public method tst args {puts [self]};
a::b public method tst args {puts [self]};

a tst; #works, returns ::a
a::b tst; #error, invalid command self

a::b eval self; #works, returns ::a::b


Thanks

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 22 Feb 2002 21:37:22 +0100

> Hm, what about this little baby:
>
> proc ::xotcl::gc {name1 name2 op} {
>
> ::uplevel $name1 destroy
>
> }
>
> Class instproc private {varname args} {
>
> ::upvar $varname v
> ::set v $varname
> ::uplevel trace variable $varname u ::xotcl::gc
> ::eval [self] create $varname $args
>
> }
>

 Hi Zoran,
 very nice!

 ...below is a still simpler version...

 with the same
 idea, we we can make a bind command, where we
 can bind an object to a variable in the sense
 that

   a) the object is deleted, when the variable is
      unset
   b) the object can provide a print-value, when
      someone read the value of the variable
 
 this might be useful for e.g. associations as well,
 where you have an instance variable refering to
 an object, and once you delete the object (with its
 variables) you want to destroy the referred object
 (or decrement a reference counter)

 -gustaf
PS: i have a little bad feeling about filters/mixins
 and uplevel/upvar and friends.
 
#### private
proc ::xotcl::gc {name1 name2 op} {
    puts "destroying $name1"
    $name1 destroy
}

Class instproc private {varname args} {
    ::uplevel trace variable $varname u ::xotcl::gc
    ::uplevel set $varname [::eval [self] create $varname $args]
}

##### bind
proc ::xotcl::value {name1 name2 op} {
    uplevel set $name1 [list [$name1 value]]
}

Object instproc bind {object varname} {
    ::uplevel trace variable $varname u ::xotcl::gc
    ::uplevel trace variable $varname r ::xotcl::value
    ::uplevel set $varname $object
}


#### usage
Class foo
foo private bar

Class C -parameter i
C instproc value {} {
    return "[self]'s value is [[self] incr i]"
}

Object o
o proc test1 {} {
    Object private o1
    puts ...
    o1 set x 1
    puts ...
}
o proc test2 {} {
    C o2 -i 11
    puts ...
    [self] bind o2 o2
    puts ...$o2...
    puts ...$o2...
}


puts =====
o test1
puts =====
o test2
puts =====