Shouldn't Spec.findKey be a class method?

I’m not sure if this is a bug or if I’m just confused about the way it’s intended to be used: whereas Spec has a class method *add, its findKeys is an instance method, so something like

Spec.add(\foo, [0, 10, \lin, 1, 1]);
Spec.findKey(\foo); // throws error because it's not a class method

A workaround is to do instead of that last line:

Spec.specs[\foo]; // ok

Neither of these three two work either (as one might expect/hope given Pdef):

Spec(\foo) // nil
Spec[\foo] // error
Spec().findKey(\foo) // also nil

findKey implies that you have something (what kind of something isn’t clear just from the name, but let’s go on) and you want it to (try to) find the key under which that something is stored.

That is, \foo is the unknown that you want to get as the output of the method.

If you already know the key \foo, then you don’t need to findKey.

Since we’re talking about Specs, then “something” should be a Spec instance. Now, the interface could be Spec.findKeyFor(instance) but then there’s a possibility that the user could pass in a wrong object (and a clever incoming user might rightly complain that the interface is too loose, or unsafe). But if the interface is aSpecInstance.findKey then it’s guaranteed, if it’s dispatched into this implementation of findKey, this must be a Spec.

Notice that findKey takes no additional arguments – so the (\foo) is simply ignored, doesn’t matter what you pass here.


I see now findKey ia a reverse (by-value) lookup in the global/classvar specs…

I guess the only thing one might actually complain about then is that Specs lacks a “get”, or in preferred SC terms an at class method.

That’s fair, actually – some (perhaps even most) classes with global storage have an at class method (Library, Archive, SynthDescLib) but Spec missed out on that. There’s not a good reason why, just, nobody did it.

You could put in a pull request for it: only need to add the method and documentation (docs would be short).


1 Like