Downsizing the Class Library

[mike]

From the Class Library Development Group thread:

@rdd echoed a longstanding question, “Is the ‘tiny core with many libraries’ approach worth considering?” and invited comments:

Development Group: class library / sclang

Not quite sure where this fits in, hopefully it’s not off-topic here, though it’s a bit of a “meta” question. I’m curious about the “culture” (for want of a better word) around libraries. For instance, CondVar seems to have been added to the “core” libraries in 2021, and I’m curious why? It doesn’t seem to require any language primitives? It doesn’t seem to be used anywhere else in the “core”? It seems like it’s just an ordinary library? It’s used by UnitTest, which seems to have been adde…

@josh mentions that it’s likely necessary that we have a robust Quark system with a dependency manager before refactoring the classlib:

Development Group: class library / sclang

If we could overhaul Quarks a bit - perhaps into something that allows for includes or something like a dependency manager - I’d actually prefer a smaller set of base SCClassLibrary classes.

@shiihs clarifies the distinction between quarks and “libraries”, and points toward (the lack of) namespaces to manage collisions of third-party code

Development Group: class library / sclang

UnitTest (and CondVar) are used in the automated builds for testing so to me it makes sense to put it in the core lib. I don’t think there’s a special resistance to using quarks, but there’s sometimes a bit of a problem of discoverability - not everyone submits their quarks into the official quarks repository (I’m guilty of that) and then it can be harder than needed to find out about their existence. In part this is because until recently I had no idea how to submit it (documentation perhaps …

@jamshark70 compares to Pd’s concept of a vanilla library, with concern that you shouldn’t need to install externals to get a decent sounding set of basic filters

Development Group: class library / sclang

Condition has always been in core, along with Semaphore. Probably around 2021, I proposed a fix for Condition, for true timeout support. The decision at that time was that Condition wasn’t a real condition variable, and that this would lead to a variety of structural problems down the road, so it would be better to add a real condition variable class, as a replacement for Condition. Since Condition is in core, it made sense to put CondVar in core. Of libraries, I wouldn’t have a problem with …

@jordan: +1 for a smaller library, mentioning

@jordan

There is also a bunch of old unused code floating around.

and later brings up the complicated issue of how do we (and have we historically) handled breaking changes to the library?

Development Group: class library / sclang

One glaring issue we haven’t discussed is our position on changes that breaks: people’s supercollider only code, supercollider code that uses things we consider backend quarks The issue with the second point is that there is no private implementation and all the ‘backend’ is actually public, meaning any changes will break something. We have an ‘ObeaseObjectProgramming’ model where the smallest thing possible in supercollider (Object) is overburden with too much responsibility. Each method in…

@muellmusik brings some historical context and raises the important point: it can only happen if one or a few core people really commit to a coherent plan.

Development Group: class library / sclang

The ‘tradition’ in SC is to allow substantially breaking changes for major new versions, which have usually been fairly big rethinks. An SC4 would be great, and would definitely be the time for major cleanup, but would need a large amount of commitment and vision. It’s been discussed for years, with lots of contradictory proposals, so I think it can only happen if one or a few core people really commit to a coherent plan. Regarding breakage: I think moving some things into Quarks is okay, as lo…

@jordan: Supercollider does not have non-user space because there are no private methods. … Breaking everything and implementing access specifies might allow us to never break anything again… that might be worth it.

Development Group: class library / sclang

Supercollider does not have non-user space because there are no private methods. Every method is available everywhere at all times. With that in mind, I don’t see how it is possible to make any changes, only add new features, without breaking something. Breaking everything and implementing access specifies might allow us to never break anything again… that might be worth it. I think what @muellmusik suggested was that a ‘painless’ breaking of user code might be a pragmatic metric. As a non-w…

@muellmusik: While there’s no namespace there are conventions like “pr” private methods, “the case for splitting things should consider the specifics carefully and where things are really causing issues”, and the JITLib case, and a library/quark that provides the split-off libs for easy transition/recovery

Development Group: class library / sclang

This is true in a formal sense, but by convention some methods are marked as private, eg with pr prefix or noted in the documentation. I don’t think there’s any issue with changing private implementation in this way, especially as in most cases the intended public interface is clear. Such changes have been relatively common over the decades for what it’s worth. I think a common sense approach to this is okay. Yeah. Though to be honest I sometimes think the case for splitting things should con…

the discussion of “public/private” methods continues for a few posts, whether private methods should be more strictly enforces/designed, see the original thread for those.