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