On Dec 15, 2006, at 1:54 PM, carmen wrote:
If we are going to have full-fledged namespaces, than this is an essential step. Think C without any #includes or Java without any #imports. Only the bare minimum is in the language itself. Everything else is a library.
in Python 2.5, Tk is still a configure-time option, which means, TkInter isnt shipped as a seperate library (Even TCL ships Tk seperately). likewise, the JVM from sun includes a GUI as well. the Squeak VM includes a gui, debugger, source code editor, etc.
these GUIs may be shipped as nonoptional parts of the core, but presambly they do have their own namespace and installation directory on disk - does this mean we'll be cerating [iemgui/ numbox2]'s in patches soon (or [declare import iemgui] or whatever)?
my question would be... what do you get out of this change. other than make people's patches slightly harder to build, and have to worry about getting your changes incorporated into miller's version or continually move around files every version bump..
i guess the prefs dialog has a setting for default library imports?
If those files are then included in the "extra" folder in the pd- vanilla, then there would be no change in how you use it. Pd would just load the file when requested, instead of at startup.
On Pd-extended those files would be stuck into a libdir. If you use the prefs file that is included in all of the Pd-extended packages, then this change would be completely transparent, you would do everything the same. Otherwise, the [import], [declare] stuff would need to be used.
Then it would mean that Pd would only load the code that you are actually using. That means you can completely ignore any bugs, etc in code that you are not using.
This also means that there would be very few reserved words in Pd. Classes compiled into the core are basically reserved words, you can't use them in any other way.
.hc
------------------------------------------------------------------------
Access to computers should be unlimited and total. - the hacker ethic