On Mon, 5 Feb 2001, Gustaf Neumann wrote:

Somehow, i have the feeling, that Kristoffer intended a class to the method "whatever". Why not use:

 Class Bar -superclass Foo
 Bar instproc init {} {
   next myArg
   [self] whatever niceSystem
 }

Because the "whatever" method should be called along with the object creation -- and specifically before it takes place. Just as if I had created an object of the superclass with -whatever in the init line.

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

...

...

...

...

"KL" == Kristoffer Lawson setok@fishpool.com writes:

KL> On Mon, 5 Feb 2001, Gustaf Neumann wrote:

...

Somehow, i have the feeling, that Kristoffer intended a class to the method "whatever". Why not use:

Class Bar -superclass Foo Bar instproc init {} { next myArg [self] whatever niceSystem }

KL> Because the "whatever" method should be called along with the object KL> creation -- and specifically before it takes place. Just as if I had KL> created an object of the superclass with -whatever in the init line.

The "-methods" are not executed by init, but by create . The Class allocs the objects, obtains default values, calls the "-methods" and finally calls init (if it was not triggered by -init in the "-methods").

If you say that the execution of "whatever" should happen before init, and you want to magically add "-methods", i would recommend to refine the create method....

-gustaf

...

...

...

...

"KL" == Kristoffer Lawson setok@fishpool.com writes:

KL> Yes, maybe that would be the best option. The issue stems from KL> the problem that I have a few different ways to create an instance KL> (and as I can only have one constructor I must do it some other way). This KL> is fine normally, but in this particular case a sub-class can only be KL> created in one manner and thus it should make an instance of itself KL> using one particular initialisation procedure of its super-class. KL> So if you have suggestions for that, I'd like to hear them. Overriding KL> create is one way, if nothing else.

i have to admit, that i do not fully understand the problem. the following seems to satisfy your needs:

Class GeneralClass Class NormalClass -superclass GeneralClass Class SpecialClass -superclass GeneralClass

GeneralClass instproc init1 .... GeneralClass instproc init2 ....

NormalClass instproc init ... { .... init1 ....} SpecialClass instproc init ... { .... init2 ....}

the other approach is to make init more clever. i read a hint from your mail, that you want to have different constructors for different parameters ("overloading similar to c++"). What's wrong with a switch in init handling these cases:

Class C -parameter situation C instproc init {} { next switch [[self] set situation] { green { .... init1 ....} red { .... init2 ....} default ..... } }

C c1 -situation green C c1 -situation red

-gustaf

KL> Btw. any ideas when 8.4 will be out? The bug with the destruction of KL> objects and error handling is causing some small headaches in the KL> debugging phase of code here. I really hate to pressure you like this, but KL> I need to be able to look forward to a bright future when I get into that KL> situation, so I can say "Oh, it'll be alright soon" when I stumble across KL> that situation. No panics though.

we have done a substantial redesign of object and class creation/recreation/deletion. Many things that were hard-wired before are now modifiable from within XOTcl. We have now a solution that looks promising to both, the "[self] destroy" problems and the issue of recreating classes and objects. We have still the hope to get the next release this week done. i can't name dates for now, but 0.84 will be out soon.

-gustaf

On Mon, 5 Feb 2001, Rick Hedin wrote:

Hi Kristoffer.

This behavior seems correct. You are trying to pass three arguments:

1. myArg 2. -whatever 3. niceSystem

to one formal parameter:

arg

We could send one argument:

next {myArg -whatever niceSystem}

or use the special properties of the args keyword:

Foo instproc init {args} { . . .

Am I looking at this right?

No, that wasn't the point. When normally creating an object you can call other methods along with the initialisation procedure (this is mentioned in the section of the tutorial about parameters, IIRC). So the following works:

Class Foo Foo instproc init {arg} { puts "arg: $arg" } Foo instproc anotherMethod {param} { puts "param: $param" }

set foo [Foo new initArg -anotherMethod methodParam]

Output: param: methodParam arg: initArg

This can often be extremely handy (and a nice feature of XOTcl). But apparently this does not work with [next] and init. It's not exactly documented that it doesn't work, but it would feel natural to assume that.

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