Mikko Ahonen wrote:
Hmm, here follows a question about controlling the order of initialization.
For example, let's assume we want to create a radio button group with individual radio buttons as kids. The invidual radio buttons are generated automatically based on the arguments passed to make-instance of the radio button groups.
Thus, the kids are generated in the initialize-instance of the radio button group. They must get created before call to apply-next-method. The problem is that when I generate the child here, it wants to read stuff from the parent, which is not yet completely initialized. For example, it wants to read which kid is selected (parent's selected cell) before any kids even exist!
I guess this is more generic problem of controlling the order of initialization of children, and perhaps delaying it until after the initialization of the parent. How do people usually go about doing this?
I can think of some work-arounds. For example set parent's selected cell to nil, and then ignore this value in kids. Or define some new state cell in the parent, which children watch for.
But isn't this a quite generic need in cells programs?
Yes, and in the first few days I suspected this (instances coming and going while being interdependent) was where the apparent wonderfulness of Cells would fall apart. :) When it didn't I had another reason to suspect we were onto something Deeply Correct.
But you do have to stay with the Cells paradigm, and it sounds like you are just a bit outside that if you are making kids in initialize-instance.
Instead, make them in a rule on the kids slot of family. But "kids" was generalized recently so you can also make them in a rule on any slot for which you also specify ":owning t", a Cells extension.
There should be a pile of examples in the test code.
kt