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__