No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Initialisation arguments
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 21 Oct 2006 11:32:37 +0200
Kristoffer Lawson schrieb:
>
> On 21 Oct 2006, at 11:33, Gustaf Neumann wrote:
>
>> 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.
>>
>> Does this help?
>
> No, I didn't mean per-object parametrisation, but the arguments passed
> to the constructor itself. F.ex.
>
> Class Foo
>
> Foo instproc init {name parent} {
> ....
> }
configure gets all arguments, including the values passed to init. Use
the one-liner of my last mail, and you
will see that this works for your example as well. if you pass the saved
values to object creation, you achieve
both, configuring the attributes and calling the constuctor with the
saved values.
>
> Mixins are probably risky here as the 'init' method does not have to
> call [next]. I could do this with a filter, I guess, or perhaps by
> overloading [create].
mixins are in no way more "risky" than a filter or overloading "create".
The mixins are in the precedence order
before the intrinsic class tree. So, it does not matter whether or not
someone has overloaded in the intrinsic
class tree "configure", and/or forgotten to write a next there.
-gustaf neumann
Date: Sat, 21 Oct 2006 11:32:37 +0200
Kristoffer Lawson schrieb:
>
> On 21 Oct 2006, at 11:33, Gustaf Neumann wrote:
>
>> 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.
>>
>> Does this help?
>
> No, I didn't mean per-object parametrisation, but the arguments passed
> to the constructor itself. F.ex.
>
> Class Foo
>
> Foo instproc init {name parent} {
> ....
> }
configure gets all arguments, including the values passed to init. Use
the one-liner of my last mail, and you
will see that this works for your example as well. if you pass the saved
values to object creation, you achieve
both, configuring the attributes and calling the constuctor with the
saved values.
>
> Mixins are probably risky here as the 'init' method does not have to
> call [next]. I could do this with a filter, I guess, or perhaps by
> overloading [create].
mixins are in no way more "risky" than a filter or overloading "create".
The mixins are in the precedence order
before the intrinsic class tree. So, it does not matter whether or not
someone has overloaded in the intrinsic
class tree "configure", and/or forgotten to write a next there.
-gustaf neumann