Frank Barknecht schrieb:
From a user's perspective, I would like to be able to write such things with dots like using [maxlib.gauss] and [footils.gauss] in one patch, assuming both gauss are different external objects in the "namespaces" maxlib and footils.
Then we would only need to manage the toplevel namespaces, which probably would be less work than having to manage all external's names.
I think we should try to find a way to avoid nameclashes! Taking the above example, someone might only be using the maxlib library and thus [gauss] is perfectly allright. Let's say someone else is running Pd with footils library, there one would get gauss from footils... Not what we want, I guess!
On the other hand, I think, it would be rather easy to implement a mechanism that tell's pd from which library to load an object from when typing [libraryname.objectname]. This could be used to force Pd to use gauss from maxlib, not from footils in case both are present. But, right, this makes object boxes much longer.
BTW, what does Pd right now if there are two identical objects? Does the one win that is loaded into Pd first? (I gues the order is Pd core objects -> libraries -> single externals -> abstractions ?)
I'm not sure, how a "using namespace maxlib" could be implemented or be useful in the PD programming language.
We allready have a similar thing when specifying which library to load. I don't see any differences here.
I think the best - and most difficult to implement - way would be to create objects as usual but to save information about the libraries / namespace (invisibly) in the pd patch. In case one of the libraries is missing on another machine, one would get an error message instead of an object from a wrong library. But then we still need a mechanism to force Pd to use a special library.
Olaf
Hi Olaf et al,
I think that putting the indocator in the object box would cause misery, because whenever a new name clash arose everyone would have to go edit all their patches ... worse yet, what if two libraries are merged or for some other reason the name of a library changes...
So, it would be better somehow to be able to specify where to find specific classes as part of Pd's run-time environment, similarly to how "path" now works. This isn't a real solution either though... what if you're using an abstraction which assumes a different "gauss" from that of the calling patch. I don't know what to offer for that scenario!
cheers Miller
I think we should try to find a way to avoid nameclashes! Taking the above example, someone might only be using the maxlib library and thus [gauss] is perfectly allright. Let's say someone else is running Pd with footils library, there one would get gauss from footils... Not what we want, I guess!
On the other hand, I think, it would be rather easy to implement a mechanism that tell's pd from which library to load an object from when typing [libraryname.objectname]. This could be used to force Pd to use gauss from maxlib, not from footils in case both are present. But, right, this makes object boxes much longer.
BTW, what does Pd right now if there are two identical objects? Does the one win that is loaded into Pd first? (I gues the order is Pd core objects -> libraries -> single externals -> abstractions ?)
I'm not sure, how a "using namespace maxlib" could be implemented or be useful in the PD programming language.
We allready have a similar thing when specifying which library to load. I don't see any differences here.
I think the best - and most difficult to implement - way would be to create objects as usual but to save information about the libraries / namespace (invisibly) in the pd patch. In case one of the libraries is missing on another machine, one would get an error message instead of an object from a wrong library. But then we still need a mechanism to force Pd to use a special library.
Olaf
One solution would be to have a default namespace - which everything is currently in.
New name spaces could be used with a new name space box - different from objects,numbers and messages - perhaps a box with rounded corners or something - this would be a "use namespace" box - where there was confusion you could use a qualified ("mylib::guass") name. Another kind of box could be used to give the namespace of the patch itself. The default namespace would be included in all patches I guess so that pd could be used as it without any namespaces...
This could perhaps even link into the -lib command either replacing it or allowing a namespace to be given in the lib command
-lib mylibpath mynamespace
where all the objects in the lib where forced into the namespace.
anyway just some thoughts
mark
-----Original Message----- From: Miller Puckette [mailto:mpuckett@man104-1.ucsd.edu] Sent: 10 August 2002 18:27 To: Olaf Matthes Cc: pd-list Subject: Re: [PD-dev] pure-data CVS
Hi Olaf et al,
I think that putting the indocator in the object box would cause misery, because whenever a new name clash arose everyone would have to go edit all their patches ... worse yet, what if two libraries are merged or for some other reason the name of a library changes...
So, it would be better somehow to be able to specify where to find specific classes as part of Pd's run-time environment, similarly to how "path" now works. This isn't a real solution either though... what if you're using an abstraction which assumes a different "gauss" from that of the calling patch. I don't know what to offer for that scenario!
cheers Miller
I think we should try to find a way to avoid nameclashes! Taking the
above
example, someone might only be using the maxlib library and thus [gauss]
is
perfectly allright. Let's say someone else is running Pd with footils
library,
there one would get gauss from footils... Not what we want, I guess!
On the other hand, I think, it would be rather easy to implement a
mechanism
that tell's pd from which library to load an object from when typing [libraryname.objectname]. This could be used to force Pd to use gauss from maxlib, not from footils in case both are present. But, right, this makes
object
boxes much longer.
BTW, what does Pd right now if there are two identical objects? Does the
one win
that is loaded into Pd first? (I gues the order is Pd core objects ->
libraries
-> single externals -> abstractions ?)
I'm not sure, how a "using namespace maxlib" could be implemented or be useful in the PD programming language.
We allready have a similar thing when specifying which library to load. I
don't
see any differences here.
I think the best - and most difficult to implement - way would be to
create
objects as usual but to save information about the libraries / namespace (invisibly) in the pd patch. In case one of the libraries is missing on
another
machine, one would get an error message instead of an object from a wrong library. But then we still need a mechanism to force Pd to use a special library.
Olaf
On Sat, 10 Aug 2002, Miller Puckette wrote:
Hi Olaf et al,
I think that putting the indocator in the object box would cause misery, because whenever a new name clash arose everyone would have to go edit all their patches ... worse yet, what if two libraries are merged or for some other reason the name of a library changes...
So, it would be better somehow to be able to specify where to find specific classes as part of Pd's run-time environment, similarly to how "path" now works. This isn't a real solution either though... what if you're using an abstraction which assumes a different "gauss" from that of the calling patch. I don't know what to offer for that scenario!
Yes, I see the same problem with both, the namespace/path ( which are really very similar) and the "dynamic prefix".
The solution in this case is of coures to require a hard coded prefix, like xy_gauss and xz_gauss, or a better solution if the two gauss authors find a way to communicate and put their features into one "official" gauss object.
I have to say that personally I find the only situation where "namespaces" are really important is for example to provide compatibility, say with max, jMax, etc. But this luckily is a very well defined situation.
Guenter
-
g�nter geiger -
mark -
Miller Puckette -
Olaf Matthes