Thomas Grill wrote:
Hi all,
as a by-product, it is very likely that the (discussed) namespacing-mechanism ([zexy::abs~] vs. [Gem::abs~]) would have to be implemented anyway.
Please!! Let's not use :: as the : is reserved in MacOS and then i can't emulate the namespace features for Max. Let's use . which is already common.
ok !
i've made some minor changes to the pd-sources (namely m_imp.h, s_loader.c, m_class.c) to allow namespaces when loading libraries.
they are attached.
the namespace-delimiter is "::" for now, but it can easily be changed via the "#define NAMESPACE" line in m_imp.h i am still not sure of if macOS-X allows the typing of ":" inside pd. if not, we might have to change it to "." or something. i really do not like the idea of "." since it is a filename delimiter.
anyhow: explanation with zexy:: the zexy class [list2symbol] is declared (in the zexy-code) with class_new("list2symbol") it has an alternative name [l2s] class_addcreator("l2s") when the patched pd loads zexy, the primary name of the class becomes "zexy::list2symbol" following alternatives (creators) are also created: "list2symbol" "zexy::l2s" "l2s"
this shouldn't really break anything, but enable the explicit use of an external inside an object.
a side-effect: zexy includes a "tabread4"-class, which is unusable since pd>0.32, because miller has finally imcluded it in pd. with the patched pd, it is possible to load zexy's version with [zexy::tabread4] (which gives a warning about being obsolete) and the native version with just [tabread4].
generally, native pd object-classes are left alone.
the helpsymbol (pd-patch) is not affected by the patch.
i think it might be a good idea to include it into pd, since it might bring a (final ?) solution to the namespace thread. (of course it might not prove optimal, but which solution would be ? i think this is the cleanest solution from a programmers point of view)
anyhow, i have only tested it on linux, it might prove problematic under macOS(?) and windows. is it true, that the native-objects in pd are loaded from the pd.dll under win ? we might (but not necessarily must) get a problem then with "pd::object"
mfg.casd.asdf IOhannes
diff pd-0.35-0_namespace/src/m_class.c pd-0.35-0/src/m_class.c 18,24d17 < #ifdef NAMESPACE < static char *library_name = 0; < void set_library_name(char *libname){ < library_name=libname; < } < #endif < 151,153d143 < #ifdef NAMESPACE < t_symbol *S=gensym(s->s_name); < #endif 176,187d165 < < #ifdef NAMESPACE < if (library_name){ < char namespacename[MAXPDSTRING]; < namespacename[0]='\0'; < strcat(namespacename, library_name); < strcat(namespacename, NAMESPACE); < strcat(namespacename, s->s_name); < s=gensym(namespacename); < } < #endif < 207,209d184 < #ifdef NAMESPACE < c->c_name = c->c_helpname = S; < #else 211d185 < #endif 232,240d205 < < #ifdef NAMESPACE < // like a class_addcreator < if (library_name){ < class_addmethod(pd_objectmaker, (t_method)newmethod, S, < vec[0], vec[1], vec[2], vec[3], vec[4], vec[5]); < } < #endif < 271d235 < 274,286d237 < < #ifdef NAMESPACE < if (library_name){ < char namespacename[MAXPDSTRING]; < namespacename[0]='\0'; < strcat(namespacename, library_name); < strcat(namespacename, NAMESPACE); < strcat(namespacename, s->s_name); < s=gensym(namespacename); < } < class_addmethod(pd_objectmaker, (t_method)newmethod, s, < vec[0], vec[1], vec[2], vec[3], vec[4], vec[5]); < #endif diff pd-0.35-0_namespace/src/m_imp.h pd-0.35-0/src/m_imp.h 52,57d51 < // IOhannes : added namespace support for libraries < #define NAMESPACE "::" < #ifdef NAMESPACE < void set_library_name(char *libname); < #endif < diff pd-0.35-0_namespace/src/s_loader.c pd-0.35-0/src/s_loader.c 131,133d130 < #ifdef NAMESPACE < set_library_name(classname); < #endif