On Feb 13, 2008, at 8:47 PM, Chris McCormick wrote: > On Wed, Feb 13, 2008 at 02:29:31PM -0500, Hans-Christoph Steiner > wrote: >> "Currently pdlua loads all *.lua files, which complicates working >> with *.lua modules not intended to be used as pd classes: Those would >> have to be in a directory outside of Pd's search path to not pollute >> Pd's namespace. " >> >> So how about using Pd's normal tools for handling name clashes and >> additionally, using a naming prefix like "lib" for the lua files that >> are not intended to be Pd objectclasses (as I described earlier)? >> Another possibility is using a subdir for these files. > > The problem is Hans, that this is not a nameclash issue at all. The > problem is that *all* .pd_linux and .pd files are meant to be read by > Pd as instantiable objects. This is not true for all .lua files. It's > obvious that the way around this is to make a new prefix which is > always > treated by pd-lua like .pd and .pd_linux files are (as an instantiable > object), and keep .lua files completely separate and ignored by > Pure Data. > > The existing Pd mechanism and convention for knowing what is > instantiable > is to use the file extension, which is a perfectly widespread method > across many programs and operating systems ('.exe', '.so', etc. etc.). > Sure, as yout pointed out earlier, you could put a .dll in a directory > and instantiate it in Pd if you want, but nobody in their right > mind does > that because it's not the convention and causes more problems without > fixing any. > > Adding a lib prefix or moving .lua files into a subdirectory do not > solve the fundemental problem which is that currently pd-lua thinks > that > all lua files are instantiable, when they are quite simply not. It > makes > no sense whatsoever to have Pd able to load a file type which it's not > supposed to be able to load. > > Sorry to add more noise,
The part of this whole equation that is the problem is the name clash. That's how this thread started. Frank said that if he had a support lib with the same name as another Pd objectclass, then there was a name clash. Loading a file that is not meant to be an objectclass is not really problem, AFAIK, it just won't create an object. Oftentimes people use this as a hack to load libraries. Since the core of this problem is name clashes, then why not use the existing techniques for dealing with that? I think this discussion is getting too abstract... I just this there already are far too many file extensions in Pd, I have had to do extra work because of them, and have yet to see the benefit. That's my two bits... .hc ------------------------------------------------------------------------ ---- "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list