[PD-dev] introducing deprecation to Pd

Hans-Christoph Steiner hans at eds.org
Fri Dec 17 04:11:25 CET 2004


So Pd is a platform that has been around long time and has been thru  
many renditions, so there is the inevitable build-up of cruft.  Mostly  
it seems that this cruft has stayed around, kept for compatibility  
purposes.  Since almost all of the externals are now in the CVS, we can  
now introduce a unified method of deprecation.

A good example of this would be [linuxevent], [linuxjoystick], and  
[linuxmouse].  People have built patches using these objects, but I am  
in the process of finishing up a unified, cross-platform system to  
replace these ([hid], [linuxhid], [darwinhid], etc.) and I am no longer  
going to maintain them at all.  So the three previous objects would be  
put into the "deprecated" folder, and then people who needed to use  
them would just add the "deprecated" folder to the path.

Deprecation is very common in programming environments like Java, and I  
think we should be thinking of Pd as a programming environment rather  
than an application.  Since there a number of objects that cause  
problems (conflicts, ancient code maintenance, etc.), I think we should  
deprecate them.

For when we deprecate objects, I am thinking that they should be put in  
a folder "externals/build/src/deprecated" and then removed from their  
location in CVS.  They will always be in the history of the CVS  
repository if anyone needs to get to them.

.hc

________________________________________________________________________ 
____

"[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it
away to benefit those who profit from scarcity."
							-John Gilmore
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1651 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20041216/c50b0b33/attachment.bin>


More information about the Pd-dev mailing list