Personal tools
You are here: Home development PdNamespaces

Edit history

Edit: -1 of 1
Time: 2010-08-25 17:37:59
Note: /pd/pd/dev/PdNamespaces/edit


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 ====
 1. canvas-local scope
 1. global objects
 1. reserved words

==== library path scope ====
 1. canvas-local paths
 1. parent-to-children paths
 1. 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 =
 *[ Let's Make Libraries! Forging a common path through the glorious forkiness of Pd.]
 *[ Libraries in Pure-data, A conversation with annotations]
 *[ Pure-data libraries]
 *[ |PD-dev| new loader replacement progress report]


Powered by IEM Powered by Plone Section 508 WCAG Valid XHTML Valid CSS Usable in any browser