IOhannes m zmoelnig wrote:
Martin Peach wrote:
Lex Ein wrote:
every object that is actually part of a library. The internal objects
would be pd:objectname, then the loose ones would be extra:objectname, externs:objectname or somesuch. ...?
basically this is what i proposed 2 years ago (although is used "." instead of ":"). it worked with 3 lines of code-change in pd's main source and no code-change at all in the externals.
but again, it doesn't help us with nameclashes at all (or at least with the C-function-clashes), but only helps/disturbs the pd-users to understand which objects they are using.
another strong objection is, that this will be more of a curse than a cure when libraries get renamed (and it doesn't help at all with single-external-libraries)
however, while i use the CVS, i do not think that it is a good idea, to make it *the* standard. there are people who refuse to work with the CVS (however irrational their reasons might be), other people see the CVS as a distribution platform (and not as a community-based development platform).
so i would favour some other mechanism (but have no idea which one ;-))
mfg.a.sdr IOhannes
PS: as for Gem's [counter]: it is there because it is there; i have no problem to remove it entirely - which brings us back to the old discussion to remove markEX from GEM (and probably check it into the "main" CVS); -- furthermore i really think that [counter] should be an abstraction instead of an external (as C-objects make things appear more complicated than they are)
Why not call it pix_counter like most of the other Gem stuff? I _have_ discovered that the 'pix' prefix means it's in GEM :) But having some way of referring to it as counter or pix_counter or Gem.counter would seem better. That way the GEM counter would be loaded if it was the first one found, while pix_counter would be a synonym for the counter in GEM, and Gem.counter would tell pd to use the counter in GEM and no other.
PPS: i remember having heard something about "static" functions in C; anybody can shed a light on this ....
Declaring a function static gives it file scope, so it is only known to functions in the same file. That might solve the 'shadowed declarations' error that occurs because two entities named 'exp' are found in the source.
Martin