On Tue, 26 Sep 2006, Hans-Christoph Steiner wrote:
I should add, the next key step is to remove as many classes as possible
from the root namespace (i.e. compiled into Pd).
I should add, that it should be possible to achieve proper namespacing
without moving anything out of the root namespace.
BTW, here's an idea that I consider interesting regarding namespaces.
Currently, the objectmaker of pd holds all classnames of pd and maps them
to creators using its methodtable. Now what if "the" objectmaker was just
"an" objectmaker among others? Think: namespace = objectmaker.
For example, each patch gets its own objectmaker, and each objectmaker
has a class_addanything which causes a fallback of any unknown classname
to a parent namespace. Eventually, asking for creation of a [+] box
crawls up a chain that leads back to the root namespace, if none of the
objectmakers in the chain defines a + method.
That way, we avoid coding extra namespace-handling features and avoid
creating a bunch of symbols with slashes in them and we reuse
the features already in pd.
This idea should raise a few questions and a few eyebrows but I believe
that it's an idea worth considering and which could pay off.
For many, it would be trivial to do, just compile them as individual
objects in a libdir. I've already done this for x_list.c, x_net.c, and a
couple others. Things like x_arithmatic.c will be trickier, but this
does not have to happen at once. It can happen incrementally.
I can't think of why x_arithmetic.c would be trickier, maybe you can
explain. What I believe will be really trickier are things that are even
more elementary to the pd language: [pd] [inlet] [outlet] [objectmaker]
[canvasmaker] [struct] [loadbang].
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada
_______________________________________________
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
