class lib: deprecate old OSC classes #2870
Conversation
This commit moves old OSC classes to the deprecated directory and adds deprecation errors. It also revises their help files to be more strongly worded, and removes a few references to them in other help files. For supercollider#2745.
This commit removes a reference to OSCresponderNode in the Emacs class. For supercollider#2870.
|
Can someone who uses scel verify that I haven't broken anything with 9eb62de? |
This comment adds a reminder to OSCresponder for removal of a line from Main:recvOSCmessage.
| // | / | / ~-. `-. _ _ _ | ||
| // |_____| |_____| ~ - . _ _ _ _ _> | ||
| // | ||
| ////////////////////////////////////////////////////////////////////////////// |
There was a problem hiding this comment.
This should go into SC history as the nicest deprecation message ever. Maybe we should propose its use for the code style guide!
|
While I am not against deprecation, I think it should be a VERY long cycle for these, as at least one class in JITLibExtensions depends on the old OSC classes (I depend on BroadcastServer myself, which uses OSCresponderNode). They won't be hard to fix, but still; a great deal of tutorials and documentation make use of OSCresponder instead of OSCFunc or its subset, and I can see this leading to more problems than solutions if even a year-long deprecation cycle is adopted. Why not simply make this a goal for whenever SC4 is released? Besides, what's the rush? AudioIn has been threatened with deprecation for as long as I can remember, and it still has not been deprecated even though nobody cares about SC2 any longer. |
It actually is deprecated in upcoming 3.9. #2482
That's exactly why we're deprecating them: because it is a goal for a future release to remove them, and because we don't want to rush people. I don't consider waiting from 3.5 until now to deprecate a "rush." |
|
Well, first, good. I'm glad AudioIn is finally deprecated, especially since it hasn't been relevant in over a decade. Next, you don't have to be so condescending. I know what deprecating means. In the linked thread, you suggested a year-long deprecation, "maybe more." Considering how prevalent OSCresponder and its relatives are in existing documentation AND IMPORTANT QUARKS, perhaps we should save the removal of these classes for the next major release, which would be 4.0. Any 3.x release should have them, as they have been integral for its entire lifespan. Again, I'm not against deprecation. They don't need to remain in the language for that much longer. I'm simply alarmed that the cycle has been proposed to only be a year or slightly longer than that. |
I didn't say that you didn't know what it means, only that the suggestions you made sounded very similar to deprecation. I am sorry that came off as condescending. I would appreciate it if you could take a more civil tone in your comments as well.
I didn't realize that's what you meant by your previous comment, because I assumed the "this" in "make this a goal" was deprecation, not removal. I think we're on the same page then. But, SC in general doesn't cling very closely to semantic versioning, so I don't know if that is exactly what's going to happen. I would certainly like to save removal of deprecations until 4.0. |
|
Oh! I apologize for my tone; I didn't mean to come off as argumentative, either. I hope there are no hard feelings, as I certainly hold none. :) That is what I meant, but perhaps I should have made myself more clear. I understand that OSCresponder has issues that OSCFunc fixes; I only use the latter, myself. I also don't really mind recoding various classes that would break upon OSCresponder and its ilk's removal for my own use, but I'm afraid of the issues it might cause for others that might not feel so comfortable dealing with these changes themselves. Therefore, a gentle deprecation cycle, followed by a 4.0 removal, would be ideal as far as I'm concerned, especially considering how prevalent these classes are. |
👍 No worries. I don't know if we've interacted much before and we have contributors with a variety of levels of expertise, so I was trying to take that into account. |
|
Move them to a quark when you do try to kill them so that people can just install it if they don't want to waste their time rewriting old code. Personally I don't even see them as that different and I've never seen the reason to bother to rewrite anything to use OSCFunc. |
|
Shout-out for a |
|
For the record, I tried installing scel on macOS but it seems like the install script assumes I am using a Linux operating system. I spent about half an hour fiddling with it before I let it go |
|
i installed emacs and got scel running, but i have no idea how to use this damn thing. like, how do you run code |
IIRC it's |
|
ok, seems to be working fine. |
Purpose
Fixes #2745. This PR moves the classes OSCresponder, OSCresponderNode, and OSCpathResponder to the official deprecation track, and removes and revises some information about them in the help files.
Description
The three old classes have been discouraged since SuperCollider 3.5, but were not officially slated for removal as per our current deprecation process. We plan to keep them around for another year or so before putting them to rest. This PR causes the classes to emit deprecation warnings, but otherwise changes no behavior.
The help files for the three classes have been revised to use stronger wording for the deprecation. Furthermore, all external references to the classes in the help files have been removed.