[PD] *.lua => *.pd_lua or *.l_lua?

Chris McCormick chris at mccormick.cx
Thu Feb 14 02:47:50 CET 2008


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,

Chris.

-------------------
http://mccormick.cx




More information about the Pd-list mailing list