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

[Hans-Christoph Steiner]

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