Are these stored anywhere within XOTcl? If not, I presume that information is not currently available to the script end? I'm just wondering as I think I could make good use of that with object recreation based on its serialised form.
Kristoffer Lawson schrieb:
Are these stored anywhere within XOTcl? If not, I presume that information is not currently available to the script end? I'm just wondering as I think I could make good use of that with object recreation based on its serialised form.
Kristoffer,
i am not sure, i understood your question. however, there is no hidden information in xotcl, which is not accessible for a script writer.
The default values for attributes are stored as ordinary attributes in the slot objects. the Attribute slot objects have for this purpose the attribute named "default". See: http://media.wu-wien.ac.at/doc/tutorial.html#attribute-slots
If objects are serialized with the xotcl serializer, they are serialized with their current settings. In other words, the object created after derserialization is identical to the object which was serialize.
Per default, the slot objects are created as child objects of the class. That means, if someone serializes the class as well, the default values are kept as well in the serialized state.
-gustaf
On 20 Oct 2006, at 23:11, Gustaf Neumann wrote:
Per default, the slot objects are created as child objects of the class. That means, if someone serializes the class as well, the default values are kept as well in the serialized state.
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.
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. The following should do it:
Object instmixin add [Class new -instproc configure args {my set __configure_values $args; next}]
Now we create a class and a few objects
Class C -parameter {{x 0}} C create c1 C create c2 -x 10 C create c3 a -x 100
... and print the stored configure values:
puts [list [c1 x] [c1 set __configure_values] \ [c2 x] [c2 set __configure_values] \ [c3 x] [c3 set __configure_values] ]
# outputs: 0 {} 10 {-x 10} 100 {a -x 100}
Naturally, this works for classes as well:
puts [C set __configure_values]
# outputs: -parameter {{x 0}}
Does this help?
-gustaf neumann
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} { .... }
And then I could ask of any 'Foo' object about what 'name' and 'parent' were used to create it, without the object itself having to know about this logic.
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]. I just wondered if I had overlooked something and this information might be available somehow and that if this information was stored internally, it could be exported to the script level, but I gather that it is not?
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
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.
OK, thanks, this is working for me at the moment.
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.
Yup, I got confused about the calling order, thinking that mixins are called after the other inheritance chain.
Kristoffer Lawson schrieb:
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.
OK, thanks, this is working for me at the moment.
you can certainly provide an instmixin for "init" instead of "configure", if you are only interested in the arguments passed to the constructor. However, in the general case, doing it on "configure" is better.
-gustaf neumann
-
Gustaf Neumann -
Kristoffer Lawson