[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