This is a place to explore ideas about how to design and implement namespaces in Pd. It is still very raw so please add your ideas to the page.
Definitions
- namespace
-
a set of symbols representing objectclasses which are available to be created as instances when typed into an object box in a patch canvas.
- canvas-local
-
only affects a single canvas (it is unclear whether subpatches fit in here)
- parent patch
-
a patch that has instances of other Pd objectclasses in it
- path
-
a set of filesystem paths used to find code to load when instantiating objectclasses, similar to the UNIX PATH
- single-object library files
-
a binary .pd_linux file that contains the code from only one object (e.g. bonk~.pd_linux)
- multi-object library files
-
a binary .pd_linux file that contains the code from multiple objects (e.g. Gem.pd_linux)
Scope
Scope in other languages: ScopeInC - ScopeInPython
There are two things here where scope is relevant, object names and library paths.
object name scope
-
canvas-local scope
-
global objects
-
reserved words
library path scope
-
canvas-local paths
-
parent-to-children paths
-
global library path
Loading into a Namespace
-
currently, you do not need to load a library to use it with the full namespace qualifier (i.e. zexy/symbol2list always works without an import/declare
-
in Python, you always need to import before using it (i.e. import zexy, then zexy.symbol2list
-path vs -lib
-
-stdpath is very close to Java's classpath and Python's PYTHONPATH. It is the path to look for libraries and classes
-
-lib is very close to Java's and Python's import. It loads libraries into a namespace
-
relative path support in -path in tricky and unneeded if you have getdir
Loading the file versus loading the object
There are multiple forms for storing objects on the filesystem, including abstractions, single- and multi-object library files, etc. Then there is the representation of what objects are assigned to which symbols. These don't need to be the same thing. Each patch has its own table of which symbols are attached to which objects, and this can be separate from which objects are actually loaded into memory.
One idea for handling this is to have separate tables of symbols for which object files are loaded, versus which symbols are tied to which objects for a given patch. It seems for this to be workable, there would need to be a "loaded" table, then each patch would generate its table from the loaded table. Then if an object isn't in the loaded table, the loaded table handler would go and try to load it.
Wish List Ideas
-
canvas-local namespaces
-
load libraries into canvas-local namespace from patch
-
global namespace
-
load libraries into global namespace from patch
-
message-based API for global settings: [;pd lib zexy( or [;pd path /path/to/my/extra(
-
import for loading libs in the context of the canvas
-
classpath for adding to the global path for finding libs
Namespaces for send/receive symbols
Oftentimes in libraries, some code requires global send and receives. These should use the same namespace prefix as you would to load a specific object from a specific library, i.e. [send framesync/fps]? and [receive framesync/fps]?.
Reserved words
There needs to be a small set of reserved words which are in the global namespace and cannot be overridden.
-
pd
-
inlet
-
outlet
-
inlet~
-
outlet~
-
declare/import
Classname conditions
-
help patch symbol
In Pd classes
-
patch receive name mypath/myclassname or just myclassname
In compiled classes
References