Weblog Page

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Wed, 30 May 2001 14:43:41 +0200

On Monday 28 May 2001 19:02, Kristoffer Lawson wrote:
> On Mon, 28 May 2001, Gustaf Neumann wrote:
> > Dear Kristoffer,
> >
> > are you aware of the predefined methods "new" and "newChild" (the first
> > one simplifies only the call to autoname, while the second one creates a
> > new autonamed object as an aggregated child object). These convenience
> > methods are defined in the langRef. the definition of newChild is
> > below...
>
> Yes, I'm aware of them, but they do not do what I mean. I want to
> create an object as a child of an already existing object which != [self].
> "new" creates a new object, but not as an aggregate of another object,
> "newChild" creates a new object as the child of the calling object. These
> are very convenient and I use both a lot, but the method I proposed is
> for easily aggregating a new object to anything.

We would propose a new:

Class instproc newChildOf {obj args} {
  ::set name [[self] autoname -instance [namespace tail [self]]]
  ::eval [self] create ${obj}::$name $args
}

which would be almost identical to newChild, but allows for specifying an
object name...

--UZ

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_uni-essen.de

From: Stefan Sobernig <stefan.sobernig_at_wu-wien.ac.at>
Date: Wed, 03 Oct 2007 11:43:25 +0200

I just stumbled over buggy behaviour of
the XOTcl Serializer with respect to inheritance
relationships and searchDefaults, originally encountered
under AOLServer.

% info patchlevel
8.4.14
% set ::xotcl::version
1.5
% set ::xotcl::patchlevel
.4

I could also re-produce this behaviour with
the most recent xotcl release, 1.5.5 (as there
were no changes to the serializer between 1.5.4 and
1.5.5, I assume)

The snippet attached can be used to reproduce
this behaviour in a non-AOLServer environment.
Interesting enough, the critical part
is to create an instance of the super class BEFORE
declaring the sub class. Commenting the line
"Super create super" yields a sound stream, creating
super yields a broken one.

To reproduce, do the following:
tclsh searchDefaults.xotcl
tclsh /tmp/stream

I tried to have a more thorough look but
I couldn't illuminate myself ...

//stefan

-- 
Stefan Sobernig
Institute of Information Systems and New Media
Vienna University of Economics	
Augasse 2-6
A - 1090 Vienna
`- +43 - 1 - 31336 - 4878 [phone]
`- +43 - 1 - 31336 - 746 [fax]
`- stefan.sobernig_at_wu-wien.ac.at <mailto:stefan.sobernig_at_wu-wien.ac.at>
`- ss_at_thinkersfoot.net <mailto:ss_at_thinkersfoot.net>

package req XOTcl
package req xotcl::serializer
namespace import ::xotcl::*


Class Super -slots {
  Attribute attribute -default "some_default_value"
}

# !!! critical !!!
Super create super
# !!!!!!!!!!!!!!!!

Class Sub -superclass Super
Sub create sub -attribute "some_new_value"

set stream [::Serializer all]
set f [open /tmp/stream w]
puts $f {
  package req XOTcl
}
puts $f $stream
catch {close $f}

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 28 Oct 2006 01:34:47 +0200

Scott,

good points. One can create an uninitialized object in XOTcl using the
"alloc" method.
So, the best approach for the current versions is

   1) alloc object
   2) set the defaults
   3) call configure
   4) call init

in the prerelase of xotcl 1.5.3, (2) can be achieved by the new
"initslots" method, in earlier versions
this is more tricky than needed. Since you are creating the object from
C, you don't need (3),
maybe you don't even need (2). If this is the case, you just need

   callmethod yourclass alloc name
   obj = getobject(name)
   setobjclientdata obj cd
   callmethod obj init

That should be actually slightly faster than the current createobject
interface.
If you don't need the default values, this works with already with 1.5.2,
otherwise you need the prerelease.

You find the prerelease under
http://media.wu-wien.ac.at/download/xotcl-1.5.3-alpha2.tar.gz
I made this version available for the heated discussion about tip257 vs.
tip279
http://www.tcl.tk/cgi-bin/tct/tip/279.html

i am leaving tomorrow morning for one week to the US, so i might not be
able to answer
mails for one week.

-gustaf

PS: simplifying this on the c-interface is still a good idea.



Scott Gargash schrieb:
>
> When creating XOTcl objects from C, it would be nice to be able to
> initialize the new object's clientData prior to any methods being
> invoked on the object.
>
> Right now, the only way I can think of to do this is to
> 1. create the object (which invokes "init", which can't rely on the
> ClientData)
> 2. XOTclSetObjectClientData( XOTclGetObject(), data); // Or the Class
> equivalent
> 3. Invoke some secondary, private "init"-like method that does true
> initialization
>
> It would be nice to have two new exported functions:
>
> int XOTclCreateObjectCl (Tcl_Interp* in, Tcl_Obj* name, ClientData
> data, struct XOTcl_Class* cl);
> int XOTclCreateClassCl (Tcl_Interp* in, Tcl_Obj* name, ClientData
> data, struct XOTcl_Class* cl);
>
> That initialize the XOTcl ClientData field prior to invoking "init" so
> that "init" could rely on the XOTcl ClientData being valid. This
> would make it much easier to construct XOTcl wrappers around C/C++
> objects.
>
> Is this reasonable? Is there a better way to accomplish this?
>
> Scott
>
> ------------------------------------------------------------------------
> *Notice*
> The information in this message is confidential and may be legally
> privileged. It is intended solely for the addressee. Access to this
> message by anyone else is unauthorized. If you are not the intended
> recipient, any disclosure, copying or distribution of the message,
> or any action taken by you in reliance on it, is prohibited and may
> be unlawful. If you have received this message in error, please
> delete it and contact the sender immediately. Thank you.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Sun, 28 Nov 2010 13:54:03 +0100

Victor, thanks for reporting this. It was not an "error" as in "Tcl
error", but it was an incorrect return value of the destroy method.
Therefore, it did not show up in the regression test.... Fixed in git.

All the nest
-gustaf neumann

Am 28.11.10 05:23, schrieb Victor Mayevski:
> Everything is now compiling and installing nicely, but I get another
> error when using NX or XOTcl 2.0:
>
> package req nx
> nx::Class create C
> C destroy
> can't read "__default_superclass": no such variable
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Univ.Prof. Dr. Gustaf Neumann
Institute of Information Systems and New Media
WU Vienna
Augasse 2-6, A-1090 Vienna, AUSTRIA

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Wed, 12 Jan 2011 14:39:47 +0100

Dear Krzysztof,

You might consider the OrderedComposite class from OpenACS:

http://cvs.openacs.org/browse/OpenACS/openacs-4/packages/xotcl-core/tcl/20-Ordered-Composite-procs.tcl?r=HEAD

It preserves the original definition order (via method children)
and it supports optionally sorting. The OrderedComposite has
as well a "contains" method.

-gustaf neumann

Am 12.01.11 14:00, schrieb Krzysztof Frukacz:
> Hello,
>
> I would like to use the children mechanism for my classes. When I
> create a class (lets call it B) I use -contains {...} and list other
> objects. But in init proc of B I also use this: eval C new -childof
> [self].
> I am interested in the order that children are listed. I need it to be
> fixed. I noticed that first goes the child from init of class B, then
> the ones that I add using -contains (outside the init proc).
>
> Is this order fixed? (first children created in superclesses, then
> ones from cunstructor, then ones from -contains). Also: is the order
> used in -contains fixed? Will I always get children in the same order
> that I added them?
>
> Best Regards,

-- 
Univ.Prof. Dr. Gustaf Neumann
Institute of Information Systems and New Media
WU Vienna
Augasse 2-6, A-1090 Vienna, AUSTRIA

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 13 Dec 2000 16:27:33 +0200 (EET)

On Wed, 13 Dec 2000, Laurent Duperval wrote:

> When do you use instproc vs. proc? I'm looking at the code I've written so
> far, and it's all instproc, I make no use of proc at all. So I'm wondering
> if it's because proc isn't used often or because I'm missing out on
> something really cool.

Well proc is something you use if you want a procedure that exists
only in that instance of an object. So if you want a procedure for
class Foo which doesn't appear in instances of Foo then you use "proc".
The same applies if you want to add a procedure to a single object.
I must admit I don't really use it much myself but it's good to have it
when you do need it, and really works with the dynamic nature of the
language.

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

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Tue, 30 Jan 2001 13:40:11 +0100

On Monday 29 January 2001 18:51, Rick Hedin wrote:
> Greetings.
>
> I worked through the example in the "Meta-Classes" section of the XOTcl
> tutorial. The result is the same whether myMetaClass is a metaclass or
> not. If you define it
>
> Class myMetaClass
>
> rather than
>
> Class myMetaClass -superclass Class

this is just a syntax example ... take a look at the next program example
in the tutorial:

  Class NoClassInfo -superclass Class
  ...<snip>...
  NoClassInfo Agent

you can see that "Agent" is of the class "NoClassInfo". Therefore,
changes on myMetaClass don't affect the Agent class.

If you do something, like:
  
  Class NoClassInfo
  ...<snip>...
  NoClassInfo Agent

this has an effect on "Agent" -> now it is not a class anymore, but an object
(and you've restricted the Object->info abilities).

Try now:

  Agent myAgent

which would in the first case, call:

  Agent create myAgent

and then create an object. Since Agent is not a class, you cannot derive
objects from it. Therefore, you now receive an error message:

  unable to dispatch method 'myAgent'

you will obtain the same result for any other class feature, like

  myAgent instproc ...
  myAgent instmixin ...

the sense of a metaclass is just to distinguish object and class
features ... for class object and class
features are available, for objects just the object features, like
"proc", "mixin", etc. are available.

>
> then
>
> Agent info superclass
>
> gives the same result.
>
> I understand, in theory, that one wants to derive a class from some "more
> basic" entity, but so far it seems to me that I can achieve everything I
> want to achieve by starting with a class, not a metaclass, and modifying
> it.
>
> Is there an example where being a metaclass results in different output?
>

Metaclasses give the programmer access to the class features. One important
class feature is how the language defines objects (in the Class->create and
Class->alloc methods). You require access to metaclasses only if you want to
mainpulate or extend the class features. Sometimes you may also want to
restrict certain class features, as for instance when you wrap C++ (or ITcl)
classes, which are non-dynamic. In most langauges without meta-classes or
meta-object protocolls you don't have access to these features. Thus most
often you cannot define a customized class system behavior in those languages.

Regards,

Uwe

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_xotcl.org, uwe.zdun_at_uni-essen.de

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 24 Jan 2003 20:37:41 +0100

On Friday 24 January 2003 17:48, Kristoffer Lawson wrote:
> On Fri, 24 Jan 2003, Gustaf Neumann wrote:
> > The caller can certainly do with the object whatever she wants.
> > if these are properties needed in the creation method they
> > have to be passed somehow there, or the object can be altered,
> > or one can put a mechanism on top of the creation to handle this.
> > I personally would not have a problem in using two different method
> > names for the different cases, like
> > set msg [$cmdReader getMessage]
> > set msg [$cmdReader getNewMessage]
> > or to use an option like in
> > set msg [$cmdReader getMessage -volatile]
>
> But that doesn't solve the issue. $cmdReader cannot create the object
> itself as volatile or bound to a variable as it will then be destroyed the
> minute getNewMessage returns! Or, of course it could always use uplevel
> and upvar but then every method that wants to return an object that may or
> may not be bound to a variable has to provide this extra functionality and
> argument checking. Ie. the methods need to be concerned with what the
> caller wants, and I don't believe this is necessary a good thing.

 well, completely without uplevel/upvar or the like it is hard to find
 a solution. also tie needs it. passing the options via args is not painful.
 "uplevel" is only used for -volatile, which is scope-dependent.

============================================
Class Msg
 
Class CmdReader
CmdReader instproc getMessage args {
  uplevel [concat [list Msg new] $args]
}

Class Client -parameter reader
Client instproc read {} {
  my instvar reader
  set msg [$reader getMessage -volatile]
}

Client c1 -reader [CmdReader new]
============================================

The instvar "reader" is btw. a good example, where i prefer control
in the new command rather than in the calling environment.
"tie" is here no good solution either. "new -refcount" would be
much nicer ....
  
> Again, I'm not saying this feature is absolutely essential, but if one
> decides to add it I believe it should be done in the best possible way ;-)

these discussions are great. we have a young language/extension, where
we can try to find "the right" way (whatever this is) and we can implement
it with not to much hassle...

-gustaf

-- 
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: Tue, 29 Mar 2005 11:36:24 +0200

Dear Aamer,

the general problem is quite tricky, when one serializes and saves some
objects
(e.g. containing ::xotcl::__#0), ends and restarts xotcl, creates again
global
objects with 'new' and restores the saved state containing the object
mentioned
above. 'Serialize all' does not save objects from the ::xotcl namespace,
but certainly
people can use -childof...

The most simple solution is to remember the highest allocated id with the
saved state in serialize all, to provide a function to reset it and
leave the problem
to the programmer. But still, this is no good solution, if multiple save
states are
used and loaded in arbitary order.

A better solution is to
  a) check in 'new', whether an object with the generated autoname
exists already, and
  b) provide a wrapper for loading the serialized code that extracts all
patterns
      of autonames, and remaps some or all symbols if necessary (for
handling preexisting
      objects with autonames). This could be done by searching for
autoname patterns
      during serialization and using similar to the -map option of the
Serializer....;
      but still, this only works, when the autonamed objects are
serialzed; for references
      in variables we would need a global map table, which is still
depending on the
      restore order of the serialized code if multiple pieces are saved.....

 What are you trying? would (a) be sufficient for you? It is slightly
slower than the
 current version, but i don't think it is worth adding another option to
new for checking
 on demand...

best regards
-gustaf neumann
Aamer Akhter schrieb:

>I just tried this with 1.3.6 and it appears to be working. Sort of
>related question, how do people handle the swizzling/unswizzling of
>autogenerated object names (eg ::xotcl__#0) when restoring an object?
>
>

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Wed, 30 May 2001 14:41:56 +0200

Hi,

we're not aware of any XOTcl Debugger (and haven't tested TclPro) ...

I guess, you know already the xotcl::trace package (in lib/trace.xotcl)
which contains some useful debugging features ...

--UZ



On Wednesday 23 May 2001 22:04, you wrote:
> Hello all.
>
> I have been just using puts to debug my xotcl code. Is there a debugger
> that works? TclPro seems to have some problems with Xotcl, or I don't
> understand how to use TclPro.
>
>
> Regards,
>
> Rick
>
> Today's mighty oak is just yesterday's acorn that held its ground.
>
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_wi.wu-wien.ac.at
> http://wi.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_uni-essen.de