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

[Hans-Christoph Steiner]

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