Xotcl February 2001

xotcl@alice.wu.ac.at

6 participants
14 discussions

Annoucing new init+destroy scheme
by Uwe Zdun 07 Feb '01

07 Feb '01

Dear XOTcl Community, Annoucing new init+destroy scheme: Due to constant questions and problems regarding object destroy + creation + recreate, we have decided to provide a new destroy scheme in XOTcl 0.84. It will have only slight observable differences to the current destroy scheme, but is more flexible and allows for recreation. I'll explain how it is currently implemented: "create" and "alloc" are both now Class instprocs handling creation for their instances. I.e. [self] alloc is wrong ... correct is now: <className> alloc [self] There is a new method "instdestroy" on Class that handles physical destruction of an object. The method "destroy" on Object has now the behavior: Object instproc destroy args { [[self] info class] instdestroy [self] } Everything is written in C ... I'll use XOTcl code just for explanation... "create" now distinguishes between: 1) creating a new object: calls alloc + <doInitializations> 2) recreating an existing object calls: [self] class <givenClass> [self] cleanup ;# resets <self> into a state as after original <init> <givenClass> recreate [self] "recreate" is a new method that can be customized. Its default behaviour is: <doInitializations> <doInitializations> is called in C and is the same for recreate and (1): - search for parameter default values - call "-" initialization methods - call "init" each of those will have a method call that can be changed, intercepted, etc. Of course, you can also overload or intercept cleanup, recreate, instdestroy, etc. Comments? Greetings, 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

Widgets
by Rick Hedin 06 Feb '01

06 Feb '01

Hello all. I want to build an object on top of a canvas. The object adds some internationalized features. I'm not clear how to manage the XOTcl object in conjunction with the Tk object. For now, I'm just managing the two as separate entities. Icanvas icanvas .f ;# I pass the path for the tk object. pack .f.icanvas -fill both -expand true ;# And manipulate the tk object with tk commands. Or maybe I should: pack [icanvas tkpath] -fill both -expand true Or give my object a truly wicked name: Icanvas .f.icanvas ;# Will this work? Or wrap every tk command in my xotcl object. What is your thinking regarding widgets from XOTcl? Regards, Rick

4 7

Widgets
by Rick Hedin 06 Feb '01

06 Feb '01

Thanks for the interesting responses. So people are: 1) Using a broker to associate Tk objects and XOTcl objects. 2) Using a filter to intercept Tk commands. 3) Wrapping a Tk object in an XOTcl object. Maybe some day we can integrate the Tk object commands with the XOTcl object commands. I would like to help, but if I do it, I won't get to it for years. (The part of the project that would need that functionality is that far off.) Regards, Rick

1 0

Probable bug: no method calls with "next" & init
by Kristoffer Lawson 06 Feb '01

06 Feb '01

[~] Class Foo [~] Foo instproc init {arg} { puts "arg: $arg" } [~] Foo instproc whatever {system} { puts "sys: $system" } [~] Class Bar -superclass Foo [~] Bar instproc init {} { next myArg -whatever niceSystem } [~] Bar ob called "next" with too many arguments - ---------- = = ---------//--+ | / Kristoffer Lawson | www.fishpool.fi|.com +-> | setok(a)fishpool.com | - - --+------ |-- Fishpool Creations Ltd - / | +-------- = - - - = --------- /~setok/

3 11

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 February 2001