Xotcl November 2000

xotcl@alice.wu.ac.at

3 participants
11 discussions

XOTcl Introductory Example
by uwe.zdun＠uni-essen.de 30 Nov '00

30 Nov '00

Hi all, for the XOTcl release 0.83, which is just announced, I've produced a simple introductory example for our tutorial. Since we have read quite often the demand for examples in the object-oriented extensions, we decided to post this example to the mailing list. Hopefully it gives you an impression of XOTcl without requiring you to read through the whole tutorial. We hope that it can demonstrate that XOTcl is (a) an dynamic object-oriented language in the style of Tcl and that XOTcl is (b) not "just another object-oriented extension." In fact XOTcl's language constructs explicitly aim at the complexity in a component glueing layer, that *IS NOT* solved by traditional object-orientation in the style C++ or Java. The expression power of the constructs is shown the best, when they work on a lot of classes, which wrap substantial real-world software components ... this obviously cannot not be achieved with an introductory example. However -- for your amusement -- here is the soccer club example with many comments (you can also find it on http://www.xotcl.org/doc/tutorial.html#soccerClub in html format, which is perhaps more readable): ############################################################################## # This is a simple introductory example for the language XOTcl. # It demonstrates the basic language constructs on the example of # a soccer club. # All the characters in this example are fictitious, and any # resemblance to actual persons, living or deceased, is coincidental. # In XOTcl we do not have to provide the above file description # as a comment, but we can use the @ object, which is used generally # to provide any kind of information, metadata, and documentation on # a running program. Here, we just give a file description. # Now makeDoc.xotcl will automatically document this file for us. @ @File { description { This is a simple introductory example for the language XOTcl. It demonstrates the basic language constructs on the example of a soccer club. } } # # All things and entities in XOTcl are objects, a special kind of objects # are classes. These define common properties for other objects. For a # soccer club, we firstly require a common class for all kinds of members. # # Common to all members is that they have a name. Common properties defined # across all instances of a class are called "parameter" in XOTcl. # Class ClubMember -parameter {name} # A special club member is a Player. Derived classes can be build with # inheritance (specified through 'superclass'). Players may have a # playerRole (defaults to NONE): Class Player -superclass ClubMember -parameter {{playerRole NONE}} # Other club member types are trainers, player-trainers, and presidents Class Trainer -superclass ClubMember Class President -superclass ClubMember # the PlayerTrainer uses multiple inheritances by being both a player # and a trainer Class PlayerTrainer -superclass {Player Trainer} # # Now we define the SoccerTeam class. # Class SoccerTeam -parameter {name location type} # We may add a player. This is done by a method. Instance methods are # in XOTcl defined with 'instproc'. All club members are aggregated in # the team (denoted by :: namespace syntax). SoccerTeam instproc newPlayer args { # we use a unique autoname for the object to prevent name # collisions, like <soccerteam>::player01, <soccerteam>::player02, ... eval Player [self]::[[self] autoname player%02d] $args } # A player can be transfered to another team. The player object does # not change internally (e.g. the playerRole stays the same). Therefore we # 'move' it to the destination team. SoccerTeam instproc transferPlayer {playername destinationTeam} { # We use the aggregation introspection option 'children' in order # to get all club members foreach player [[self] info children] { # But we only remove matching playernames of type "Player". We do # not want to remove another club member type who has the same # name. if {[$player istype Player] && [$player name] == $playername} { # We simply 'move' the player object to the destination team. # Again we use a unique autoname in the new scope $player move [set destinationTeam]::[$destinationTeam autoname player%02d] } } } # Finally we define two convenience methods to output the members or players: SoccerTeam instproc printMembers {} { puts "Members of [[self] name]:" foreach m [[self] info children] {puts " [$m name]"} } SoccerTeam instproc printPlayers {} { puts "Players of [[self] name]:" foreach m [[self] info children] { if {[$m istype Player]} {puts " [$m name]"} } } # Now let us build two example soccer teams: SoccerTeam chelsea -name "Chelsea FC" -location "Chelsea" SoccerTeam bayernMunich -name "F.C. Bayern München" -location "Munich" # With 'addPlayer' we can create new aggregated player objects # # Let us start some years in the past, when "Franz Beckenbauer" was # still a player. set fb [bayernMunich newPlayer -name "Franz Beckenbauer" \ -playerRole PLAYER] # 'playerRole' may not take any value. It may either be NONE, PLAYER, # or GOALY ... such rules may be given as assertions (here: an instinvar # gives an invariant covering all instances of a class). In XOTcl # the rules are syntactically identical to 'if' statements Player instinvar { {[[self] set playerRole] == "NONE" || [[self] set playerRole] == "PLAYER" || [[self] set playerRole] == "GOALY"} } # If we break the invariant and turn assertions checking on, we should # get an error message: $fb check all if {[catch {$fb set playerRole SINGER} errMsg]} { puts "CATCHED EXCEPTION: playerRole has either to be NONE, PLAYER, or TRAINER" # turn assertion checking off again and reset to PLAYER $fb check {} $fb set playerRole PLAYER } # But soccer players may play quite different, orthogonal # roles. E.g. Franz Beckenbauer was also a singer (a remarkably bad # one). However, we can not simply add such orthogonal, extrinsic # extensions with multiple inheritance or delegation. Otherwise we # would have either to build a lot of unnecessary helper classes, like # PlayerSinger, PlayerTrainerSinger, etc., or we would have to build # such helper objects. This either leads to an unwanted combinatorial # explosion of class or object number. # # Here we can use a per-object mixin, which is a language construct # that expresses that a class is used as a role or as an extrinsic # extension to an object. # First we just define the Singer class. Class Singer Singer instproc sing text { puts "[[self] name] sings: $text, lala." } # Now we register this class as a per-object mixin on the player object: $fb mixin Singer # And now Franz Beckenbauer is able to sing: $fb sing "lali" # But Franz Beckenbauer has already retired. When a player retires, we # have an intrinsic change of the classification. He *is* not a player # anymore. But still he has the same name, is club member, and # is a singer (brrrrrr). # Before we perform the class change, we extend the Player class to # support it. I.e. the playerRole is not valid after class change # anymore (we unset the instance variable). Player instproc class args { [self] unset playerRole next } # Now we can re-class the player object to its new class (now Franz # Beckenbauer is President of Bayern Munich. $fb class President # Check that the playerRole isn't there anymore. if {[catch {$fb set playerRole} errMsg]} { puts "CATCHED EXCEPTION: The player role doesn't exist anymore (as it should be after the class change)" } # But still Franz Beckenbauer can entertain us with what he believes # is singing: $fb sing "lali" # Now we define some new players for Bayern Munich: bayernMunich newPlayer -name "Oliver Kahn" -playerRole GOALY bayernMunich newPlayer -name "Giovanne Elber" -playerRole PLAYER # if we enlist the players of Munich Franz Beckenbauer is not enlisted # anymore: bayernMunich printPlayers # But as a president he still appears in the list of members: bayernMunich printMembers # Now consider an orthogonal extension of a transfer list. Every # transfer in the system should be notified. But since the transfer # list is orthogonal to SoccerTeams we do not want to interfere with # the existing implementation at all. Moreover, the targeted kind of # extension has also to work on all subclasses of SoccerTeam. Firstly, we # just create the extension as an ordinary class: Class TransferObserver TransferObserver instproc transferPlayer {pname destinationTeam} { puts "Player '$pname' is transfered to Team '[$destinationTeam name]'" next } # Now we can apply the class as a per-class mixin, which functions # exactly like a per-object mixin, but on all instances of a class and # its subclasses. The 'next' primitive ensures that the original # method on 'SoccerTeam' is called after notifying the transfer (with # puts to stdout) SoccerTeam instmixin TransferObserver # If we perform a transfer of one of the players, he is moved to the new # club and the transfer is reported to the stdout: bayernMunich transferPlayer "Giovanne Elber" chelsea # Finally we verify the transfer by printing the players: chelsea printPlayers bayernMunich printPlayers ############################################################################## -- Uwe Zdun Specification of Software Systems, University of Essen Phone: +49 201 81 00 332, Fax: +49 201 81 00 398 zdun(a)xotcl.org, uwe.zdun(a)uni-essen.de

1 0

XOTcl 0.83 available
by Gustaf Neumann 30 Nov '00

30 Nov '00

Dear Tcl Community, This is the first public announcement of 'Extended Object Tcl' (XOTcl) in this mailing list. XOTcl was derived from the impressive OTcl language developed by D. Wetherall and C. Lindblad at the MIT in '95 and extended in various ways. In short, XOTcl tries to provide a highly flexible, reflective, component-based object-oriented environment. It integrates language support for high level concepts, which are not found in other languages, with reasonable performance. Nevertheless, it prevails the Tcl programming style and the dynamic/introspective nature of the language, rather than introducing other language's styles and rigidness (such as C++) into Tcl. Since it was our aim to combine new ideas from the object-oriented community with the component glueing concepts of Tcl, we presented XOTcl so far primarily to the scientific community in the areas of object-orientation, design patterns, and web development. Now we believe that XOTcl implementation has reached a fairly good quality in terms of stability, speed and memory-leaks, and therefore we decided to make this public announcement of the XOTcl release 0.83. The XOTcl paper presented at the Tcl/Tk conference in February 2000 described XOTcl version 0.80. The most important changes in the newer releases are: XOTcl Language: - improved configurability and portability - support for mixin interceptors at the per-class level (instmixins) - various new predefined XOTcl methods operating on variable names (exists, append, lappend, incr, array) - various speed improvements - deep copy/move for all aggregations - free of memory leaks and invalid memory references (tested with Purify) packages: - new documentation tool (see tutorial) - substantially improved components for XML and RDF - better support for HTML forms (e.g. file upload) - support for secure places via SSL - more example programs - improved documentation (still a long way to go) packaging: - provision of XOTcl in the RPM and SRPM format The XOTcl distribution contains aside of the implementation of the language a growing set of components. We developed them as a prove of concept that the concepts of the XOTcl language can be used as a powerful environment for practical applications. The XOTcl distribution contains for example a Web communication infrastructure (HTTP client and server), support for persistent objects, a mobile code system, important Web formats (such as XML and RDF), and general reusable components based on design patterns. General information about XOTcl and its components can be found at http://www.xotcl.org Best regards, Gustaf Neumann Uwe Zdun

1 0

Stack-Bsp.
by franziska deopito 24 Nov '00

24 Nov '00

Hallo! Habe eine Frage bezüglich des Stack-Beispiels aus der VO (Folie 66). Als Konstruktor wird [self] set elements {} geschrieben. Warum werden hier {} statt 0 gesetzt? CU Franziska

1 0

Persistence in XOTcl (was Re: pb in src/package distribution configure)
by uwe.zdun＠uni-essen.de 22 Nov '00

22 Nov '00

>>>>> "CL" == Catherine Letondal <letondal(a)pasteur.fr> writes: >> > 3) What is GDBM required for? Is it a general purpose persistence package that >> > I could use for my own needs? How can I use it within XOtcl? >> > >> >> gdbm is a nice persistence store, which allows you to make any >> XOTcl object persistent (by specifying, which vars are persistent). There >> is no documentation yet, but you can see in the counter examples in >> apps/actiweb-apps how it works. the necessary packages are in the >> packages/store dir. at the moment we are relying on gdbm, but plan to use >> also several other persistent stores soon CL> The problem is that gdbm il old (according to colleagues) and does does not install CL> easily on my workstation - so I guess there will be problems on other platforms? CL> Actually I had pbs with their ./libtool script for installing files and nobody could help! We are aware of these problems. But Gdbm is in most Linux Distributions. For Windows we provide a pre-compiled DLL. The other platforms (like Solaris) sometimes require some hand-crafting. There are several other persistent store (and databases), which we possibly will support soon behind one common object interface (like Berkley DB, MetaKit, etc.) CL> Persistence interests me *a lot*, since the environment I'm currently programming is a CL> programming environment, where 'programming exploration' is allowed by adding procs to CL> objects during the normal use session. Several types of customization - like graphic CL> attributes, bindings configuration - have also to be saved of course. CL> The idea is also to have the already existing objects and their user interface (widget) to be CL> automatically displayed when the application is restarted. CL> Saving will be done by default, I mean without the user being required to ask for it. CL> All this is realted to what you call 'programmable interfaces' in the paper 'Design and CL> Implementation Constructs for the Devlopment of Flexible, Component-Oriented Software CL> Architectures' - except that it is the so-called 'end-user programming'. CL> What's the main idea to save an object? I have seen the persistent keyword in the CL> counter examples, but how do you say: save this object, save this object's proc, etc...? There are basically two things to do in order to make an object persistent: 1. you have to set up a Persistence Manager. That is an object wrapper for the database/persistent store instance. E.g. with Gdbm it represents a GDBM file 2. you have to say which variables of which objects should be made persistent. This is done by calling the method "persistent" ... "persistent" is an instproc of the class Persistent, which you can find in store/Persistence.xotcl. This class (or one of its subclasses) has to be made per-object mixin (or per-class mixin or superclass) of the instance that should be made persistent. The subclasses of the Class Persistent are the ones you actually use. They determine the persistence strategy. Actually we have two persistence strategies at the moment: Eager and Lazy. The Eager strategy stores everything when it is written, the Lazy strategy stores the vars when the xotclsh terminates. This may sound more complicated than it actually is. Here is a simple example: #################################### # load the persistence component package require Persistence # Two example objects Object o # set two variables to default values o set x 1 o set y 1 Object p # set two variables to default values p set x 1 p set y 1 #################################### # now we make these vars persistent #################################### # 1. we need the PersistenceMgr (for gdbm we have to specify a file # name). If we want to get rid of the current setting and start again # we default values, we have to delete this file PersistenceMgr pmgr -persistenceDir . -persistenceFile example-db # 2. we have to make the objects persistent. We register the # persistence strategy as per-object mixin on the two objects # # one uses the lazy, one the eager strategy o mixin Persistent=Eager p mixin Persistent=Lazy # 3. tell the objects, which PersistenceMgr to use o persistenceMgr pmgr p persistenceMgr pmgr # 4. make the vars persistent o persistent {x y} p persistent {x y} ##################################### # now the vars are loaded from the persistence store # # we incr them to demonstrate the persistency; and print the results o incr x 2 o append y 1 p incr x 3 p append y 2 puts "Values:" puts " o->x: [o set x]" puts " o->y: [o set y]" puts " p->x: [p set x]" puts " p->y: [p set y]" # now run the program several times to see the results #################################### I will include this example in the store dir of the XOTcl distribution. Note, for XOTcl WebObjects, Agents, etc. several of the tasks demonstrated above are performed automatically ... therefore, the Counter examples look even much more simple. The WebObjects automatically associates with the PersistenceMgr of the place. Therefore a simple: [self] persistent varXXX makes the variable varXXX persistent eagerly. CL> BTW, I have already develop small things, like a spreadsheet (using a mixin class CL> to implement the dependencies between cells - see CL> http://www.pasteur.fr/~letondal/tmp/mvc-depend.html) implemented thanks to tktable. great! we have an applications web site on the XOTcl homepage and encourage everyone to put up a web site for their XOTcl apps. If you have something to reference please inform us. Regards, Uwe -- Uwe Zdun Specification of Software Systems, University of Essen Phone: +49 201 81 00 332, Fax: +49 201 81 00 398 zdun(a)xotcl.org, uwe.zdun(a)uni-essen.de

1 0

Re: XOTcl 0.83 questions (continued...)
by uwe.zdun＠uni-essen.de 21 Nov '00

21 Nov '00

Hi Zoran, we have an mailing list set up for XOTcl ... I'll cross-post this mail to the list, because it might be of general interest. Perhaps you like to CC general questions/comments to the list and/or subscribe: http://wi.wu-wien.ac.at/mailman/listinfo/xotcl We will announce the list publicly with 0.83 ... here, is some example code that shows two ways how to retrieve all instances, classes, and metaclasses in the system: --Uwe ################################################################### # set up some classes for testing # # some meta classes # Class Meta -superclass Class Class Meta2 -superclass Meta Class Meta3 -superclass Meta2 # # some classes # Class X Class Y Meta Z Meta2 A Meta2 B # # some objs # X x Object o Y y1 Y y1 A a1 A a2 # # if you only use the global namespace it is quite simple to retrieve # the instances, like: # (you can also traverse the namespaces ... but then the # variant down below is more elegant) set objects "" foreach c [info commands] { if {[Object isobject $c]} {lappend objects $c} } puts "Global Objects are: $objects" # # we can also go along the class hierarchy # # we define a separate class that computes the instances (could # also be instprocs on Object ... but then we won't have the ability # to use the code on a subclass) # Class InstanceRetrieval InstanceRetrieval instproc getAllSubClasses cl { set result "" set sc [$cl info subclass] foreach c $sc { lappend result $c set result [concat $result [[self] getAllSubClasses $c]] } return $result } InstanceRetrieval instproc getAllInstances {} { set result "" # get all subclasses of this class set subclasses [[self] getAllSubClasses [self]] # now get the instances of every subclass foreach sc $subclasses { set result [concat $result [$sc info instances]] } return $result } # now we register that class on Object as a mixin # -> we can all instances of the object class (including the # nested objects Object mixinappend InstanceRetrieval set allObjs [Object getAllInstances] puts "All objects are: $allObjs" # # with isclass and ismetaclass we can additionally sort out the # classes and metaclasses # foreach o $allObjs { if {[Object isclass $o]} { lappend classes $o if {[Object ismetaclass $o]} {lappend metaclasses $o} } } puts "All classes are: $classes" puts "All metaclasses are: $metaclasses" ################################################################### >>>>> "ZV" == Zoran Vasiljevic <zoran(a)munich.com> writes: ZV> Hi Gustaf and Uwe ! ZV> First of all, many, many thanks for your time and patience. ZV> I think I'm getting the (XOTcl) picture slowly. ZV> I could need a helping hand again, though, 'cause I'm stuck ZV> a little bit. ZV> ------- ZV> Given an initialized interpreter I would like to generate ZV> a script to re-make *all* classes/objects found there. ZV> But how to get them ? I would not like to resort to ZV> "namespace is a object/class" assumption.... ZV> Consider this: ZV> % Class TC ZV> % TC tobj ZV> Now get all defined classes ... ZV> % Class info instances ZV> ::Class::Parameter ::Class ::Object ::Object::CopyHandler ::TC ZV> Fine. The "TC" is there. ZV> % Object info instances ZV> ::@ ZV> Where is my "tobj" ? What am I doing wrong ? ZV> I cannot find the "tobj" anywhere. ZV> Also, If I somehow manage to properly collect all classes ZV> (and objects) I should somehow follow the class graph, ZV> when recreating classes, right ? Using (super/sub)class info ZV> and traversing the class tree/graph, right ? ZV> I think I could use some example, if you have some lying arround. ZV> Sincerely, ZV> Zoran Vasiljevic. ZV> ______________________________________________ ZV> FREE Personalized Email at Mail.com ZV> Sign up at http://www.mail.com/?sr=signup -- Uwe Zdun Specification of Software Systems, University of Essen Phone: +49 201 81 00 332, Fax: +49 201 81 00 398 zdun(a)xotcl.org, uwe.zdun(a)uni-essen.de

1 0

Re: XOTcl 0.83 questions (bugs?)
by Gustaf Neumann 20 Nov '00

20 Nov '00

>>>>> "Zoran" == Zoran Vasiljevic <zoran(a)munich.com> writes: Zoran> Hi Uwe and Gustaf ! Zoran> This is one of the first messages in sequence, you're going Zoran> to receive from me. I'm sorry for (eventual) inconvenience Zoran> but I have to master this great package and there is nobody Zoran> else to ask ! Dear Zoran, many thanks for your feedback. i am pretty sure, uwe is currently preparing an email concerning the assertion issues.... so i all address the later issues. Zoran> subject. Also, need some examples for "parameterclass". Zoran> Reference mentions it but the tutorial is silent abut it ??? Zoran> Have any working code which uses them ? The basic idea is to make the parameter mechanism in a similar way extensible as the extension mechanisms work for normal oo-methods. One can extend the predefined Class::Parameters class with someInstproc and use later C c1 {{a -default 1 -someInstproc x} ...} or subclcass it like Class MyParameters -superclass Class::Parameters Class X -parameterclass MyParameters -parameters ...... The parameter classes are still in an early state, we are not happy about the need to specify -parameterclass for interesting cases, and we hope to find more elegant ways to express these semantics. Here is an simple example for illustration: =========================================================================== Class::Parameter instproc comments {param args} { puts "[self] [self class] parameter: $param args: $args" } Class::Parameter instproc values {param args} { set ci [[self class] info instinvar] set valueTest {} foreach a $args { lappend valueTest "\[\[self\] set $param\] == [list $a]" } lappend ci [join $valueTest " || "] [self] instinvar $ci } Class X -parameter { {a 1 2 3 -comments a b c d e} {b -default 2 -comments 1 2 3 4} {e -default 3 -values 1 2 3} {Self -default [self]} } X instproc checkInvar {} { [self] check instinvar [self] set e 9 } X x -checkInvar Class C -superclass {Class::Parameter Class} C instproc comments {param args} { puts "[self] [self class] parameter: $param args: $args" next } Class Y -superclass X -parameterclass C -parameter { {a 1 2 3 -comments a b c d e} {b -default 2 -comments 1 2 3 4} {e -default 3 -values 1 2 3} {Self -default [self]} } Y y -checkInvar =========================================================================== Zoran> What the heck is the "@" good for ??? Zoran> I notice such constructs in your code pretty often... Zoran> Class SomeClass Zoran> @ @File {description { Zoran> This is a file which provides a blablablabla.... Zoran> } Zoran> } Zoran> What does this mean ? the @ is used for documentation issues: check out xotcl/doc/langRef.xotcl for the largest example. The basic ideas behind xoDoc are: - the comments are first class xotcl commands; by defining alternate @ commands (e.g. via per object mixins etc), one can do different things with the comments; currently, we have only the HTML backend, but the basic idea is to provide support for several other usages as well (e.g. XML, RDF, online help, documentation of dynamic structures, etc). - We have an Object "@" that handles comments via its unknown method. xoDoc adds the appropriate instprocs to @ to produce HTML output. The appropriate command is: xotclsh src/lib/makeDoc.xotcl <DOCDIR> <DOCFILES> - The source of a documentation is structurally very similar to the xotcl constructs being commented. e.g. one can copy an instproc and add comments at the right places. eg. Class C C instproc m {a1 a2} { return [expr {$a1+$a2}] } can be commented as follows @ Class C { description { "my sample class"} } @ C instproc m {a1 "first number" a2 "second number"} { description "add two numbers" return "sum of a1 and a2" } One can do essentially a copy+paste of the source and add the comments via attribute value pairs, every basic language construct can have a "description". If you want to include other properties to the description, you can add e.g. @ C instproc m {a1 "first number" a2 "second number"} { author "GN+UZ" date "Feb 31" description "add two numbers" return "sum of a1 and a2" } This way, author and date are added automatically to the generated HTML file. In addition, there is a @File hook for a per file description. Zoran> Cheer's (and thanks for help!) Zoran> Zoran Hope this helps -gustaf Zoran> ______________________________________________ Zoran> FREE Personalized Email at Mail.com Zoran> Sign up at http://www.mail.com/?sr=signup

1 0

XOTcl, threading and AOLserver ?
by Gustaf Neumann 16 Nov '00

16 Nov '00

>>>>> "Zoran" == Zoran Vasiljevic <zoran(a)munich.com> writes: Zoran> Hi ! Zoran> First of all, I'm very excited about XOTcl ! I think Zoran> you did an excellent job. Zoran> ... Zoran> Question 2: <read on> Zoran> Having nice introspection capabilities built into the Zoran> XOTcl, I wonder if one can write a Tcl script which Zoran> runs against the initialized interpreter and builds up Zoran> a script needed to re-construct all classes and/or object Zoran> which it finds there (in the interpreter)? Zoran> Why should one need this ? Zoran> Well, the AOLserver webserver which we use is a little bit Zoran> special. It sources initialization files in startup thread/interp Zoran> and then runs a series of scripts to get the interpreter Zoran> blue-print. This blue-print (in form of Tcl-code) is then Zoran> ran against each newly created interpreter. This is to Zoran> simplify and speed-up of new interpreter(s) initialization. Zoran> In order to use XOTcl in AOLserver, one should be able to Zoran> produce such a script programatically. Zoran> For plain Tcl code, this is no big deal. I think XOTcl would Zoran> not pose any problem, but nevertheless, it's better to ask. Zoran> Any comments ? Hi Zoran, there are no such problems, it is indeed quite easy to reproduce a script from Objects and classes. Here is a simple script for object serialization that you might use as an starting point. Class serialization works very similar... best regards -gustaf =========================================================================== Object instproc serialize {} { ::set o [self] if {![Object isobject $o]} { error "$o is not an object" } ::append cmd [list [$o info class] $o] \n foreach i [$o info procs] { ::append cmd [list $o proc $i [$o info args $i] [$o info body $i]] \n } foreach v [$o info vars] { if {[string match __* $v]} continue ;# internal variables if {[$o array exists $v]} { ::append cmd [list $o array set $v [$o array get $v]] \n } else { ::append cmd [list $o set $v [$o set $v]] \n } } ::append cmd [list $o mixin [$o info mixin]] \n foreach child [[self] info children] { ::append cmd [$child serialize] \n } return $cmd } Object o1 o1 set var1 100 o1 set var2 "hi there" o1 set price(potato) 10 o1 set price(tomato) 20 o1 proc test {a b} { puts "a=$a, b=$b" } Object o1::x o1::x set y 100 puts -------------------- puts [o1 serialize] puts -------------------- ===========================================================================

1 0

[forwarded] Re: XOTcl, threading and AOLserver ?
by Gustaf Neumann 16 Nov '00

16 Nov '00

1 0

[forwarded] Re: XOTcl, threading and AOLserver ?
by Gustaf Neumann 16 Nov '00

16 Nov '00

1 0

[forwarded] Re: XOTcl, threading and AOLserver ?
by Gustaf Neumann 16 Nov '00

16 Nov '00

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Xotcl November 2000