Usage of Class.initClassTree(ControlSpec) can remove common mappings

[antonhornquist]

I used this in the *initClass of a custom class:

Class.initClassTree(ControlSpec)

Afterwards I could note that the common mappings (\unipolar, \bipolar, \freq, etc) defined in ControlSpec.initClass were not available anymore when I compiled the class in 3.7.2. In 3.6.6 they still showed up.

I'm quite sure this is due to the fact that Spec.initClass is not invoked prior to ControlSpec.initClass so the common mappings are overwritten after they have been added, in the cases when Spec is inited after ControlSpec.

I think simply adding Class.initClassTree(Spec) to the top of ControlSpec.initClass would fix this problem.

[crucialfelix]

If your custom class requires those specs then it should call
initClassTree(ControlSpec)

There is no guarantee what exact order classes are initialized. That's why
initClassTree allows you to ensure a class is initialized. When you add new
classes then the order may change.

So the problem is not because controlspec or spec isn't doing something,
it's that you need them initialized so you need to request that they are
initialized before you use them.

Does that explain it ?

On Sat, Sep 3, 2016, 16:35 Anton Hörnquist notifications@github.com wrote:

I used this in the *initClass of a custom class:

Afterwards I could note that the common mappings (\unipolar, \bipolar, \freq, etc) defined in ControlSpec.initClass were not available anymore when I compiled the class in 3.7.2. In 3.6.6 they still showed up.

I'm quite sure this is due to the fact that Spec.initClass is not invoked prior to ControlSpec.initClass so the common mappings are overwritten afterwards when Spec is inited.

So I think simply adding Class.initClassTree(ControlSpec) to the top of ControlSpec.initClass would fix this problem.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2318, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AANWcpzlZN-TJNuc353ngqHlX4RpSmdbks5qmYWUgaJpZM4J0ULb
.

[antonhornquist]

Sorry if I was unclear. I am using Class.initClassTree(ControlSpec) in my custom class. It causes common mappings to disappear.

Since ControlSpec.initClass does not invoke Class.initClassTree(Spec) the common specs are overwritten when Spec.initClass - by the core SuperCollider init functionality - is invoked after ControlSpec.initClass. In my 3.7.2 SC this is the case. In 3.6.6 it's not the case.

This is a bug. The dictionary in Spec.initClass must be created before ControlSpec fills it. I can fix this in my app by initing Spec before ControlSpec explicitly myself, but I think this should be fixed in core lib. I propose to include Class.initClassTree(Spec) in ControlSpec.initClass.

I can create a pull request for this oneliner.

[antonhornquist]

Please also note that I revised the initial issue report just after posting it, it included a mixup of ControlSpec and Spec. It is probably clear if you reread it.

[crucialfelix]

OK, I see what you mean now.

nB: yes I noticed your error (that you later edited). If you actually did call Class.initClassTree(ControlSpec) it might cause the app to crash because it keeps calling it again and again. Hopefully it flags it as already-inited before calling.

[jamshark70]

Hopefully it flags it as already-inited before calling.

It does -- see the usage of classesInited in initClassTree.

[crucialfelix]

Yes, I know I wrote it. I'm just wondering (while on my telephone, out and
about wandering the earth) if I did actually do it right.

On Mon, Sep 5, 2016 at 12:41 AM jamshark70 notifications@github.com wrote:

Hopefully it flags it as already-inited before calling.

It does -- see the usage of classesInited in initClassTree.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#2318 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANWcuSETDHJfChEvj75a2BeWHCR3we_ks5qm0kFgaJpZM4J0ULb
.