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

[Frank Barknecht]

Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

> I think this kind of thing should be caused by a real world problem  
> rather than a hypothetical.  mxj uses .java and it has been used a  
> lot.  People could also write java classes that are not intended to  
> be loaded by Max and stick them in the same folder.  So far, it  
> doesn't seem to be a problem, AFAIK.

It's *not* a hypothetical problem at all. Please test it first before
jumping to wrong conclusions, see below for how. Claude and I are
already running Lua a lot and at least I have run into the problem of
nameclashes.

First: mxj for Pd (pdj) is not a loader, so it doesn't have the
problem, as you specify the filename in the object name. If you don't
specify a certain filename because it's a module, pdj won't load it.
Similar things are possible with luax, also [pyext ...] works that
way. We aren't talking about this kind of external here.

However for the pdlua loader, lua scripts shadow e.g. abstractions.
Here's how to test it: Make a lua file with this content only: 
 
 print("Hey, I shouldn't load at all")

This is not a valid Pd class written in Lua. Then make it nameclash
with any abstraction in your path by naming it e.g. "list-drip.lua"
and putting it before the abstraction into your path. Then try to
create a [list-drip]. pdlua will run the lua file instead of
list-drip.pd and print "Hey, I shouldn't load at all".  The wrong
[list-drip] will remain dashed.

All of this is *trivial* to fix with a special file ending, whereas
every other solution suggested so far is either completely impractical
("move modules outside of Pd's search path"), doesn't fix anything
("keep the status quo") or is overcomplicated and a possible
performance drain ("add code which tries to load every *.lua file but
goes on, if the file doesn't register a class properly").

Ciao
-- 
 Frank Barknecht                                     _ ______footils.org__