[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Towards SC 4

Here are some issues for the list:

(A) Method call extensibility vs consistency and reliability

(1) Current problem with the dependency model is that you get dangling references. This basically reintroduces problems that the garbage collector solved.

(2) Allegedly, the method table is becoming slow (I haven't measured this, but Tim mentioned it). But when you have to avoid adding methods and classes, code quality can suffer.

(3) Object prototyping with Environments is not safe, because pseudo-method names may be overridden by an extension to the superclasses of Environment, including Object.

(4) On the fly inclusion of functionality on a class-library level

The solution to these problems touch areas beyond my competence. Anyway, here are some ideas that I could think of:

Extend the class Object by one extra slot that could hold a reference to an object containing any of the following:

(a) dependants dictionary
(b) method extensions / uniqueMethods
(c) meta data and ad hoc features

This extra slot could be restricted to non-literals for efficiency. It would add quite a bit of memory requirement, but could directly solve (1), indirectly improve (2).

(3) could be solved by either 
(a) adding a methodless class (ProtoObject) on top of the tree
(b) by allowing objects to block method calls
(c) allowing uniqueMethods to override existing methods

(4) Has been discussed on this thread, yes, this would be very nice, and might make (3) unnecessary. It might be hard to optimise the method table on the fly though? I suppose there are algorithms that exist for these things.

(B) Duplicate or fragmented implementations

Doing the same thing in different ways makes it often hard to understand the system. At the same time it is an important feature (occam's razor doesn't apply here necessarily). Most of the following could be done in 3.8 already, I think, but it is a time intensive and error prone process.

(1) GUI-redirects (do we want to keep them?)
(2) Move non-ugen classes from sc3-plugins to Quarks
(3) Move useful methods from Quarks to Common
(4) Mark all Quarks how much they are maintained, perhaps refactor and regroup some quarks.
(5) Server and Plus-Gui extensions need refactoring. (https://github.com/supercollider/supercollider/wiki/notes-for-refactoring-the-server-implementation)

[I guess the list is rather long, adding to what others have said, we'll probably have to move to a wiki]

sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/