[PD-dev] Re: Fw: [PD] namespaces :: out now

[IOhannes zmoelnig]

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




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: namespace.diff
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20020828/db45b710/attachment.asc>