On Feb 12, 2008, at 6:44 PM, Frank Barknecht wrote:
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").
This is not something that is exclusive to lua or pdlua. This is
just a classic nameclash issue, but triggered in a new way. All of
the normal techniques of dealing with nameclashes in Pd would also
work. I think we are much better off using one generalized technique
for handling name clashes that works everywhere, than many domain-
specific techniques, like .pd_lua.
A naming convention could be one way to help the situation. For
example, how about making non-objectclass lua files have a specific
name prefix, like "lib" (i.e. libsupport.lua). Yes, this would be a
name clash with anything named 'libsupport', but I think a prefix
could be chosen that would really be rarely a problem. Then you get
all of the niceness of having the file called .lua, and very few name
clashes.
I am not arguing this for some arcane reason. All of the new Pd
binary extensions (.pd_imac, .l_i386, .m_i386, etc.) that have been
added have ended up causing me a lot of extra work in Pd-extended
with no real benefit that I could see. Even the
standard .pd_darwin/.pd_linux has created extra work.
.hc
Mistrust authority - promote decentralization. - the hacker ethic